The one absolute truth about consulting is that if you’re not working you’re not making any money. The corollary to this truth is that you are either 100% busy or 100% not busy. This is especially true if you are a solo developer. It is very hard to turn down projects when they come your way but I’ve found that there are times when you should.
I get it. Really, I do. If you’ve been idle for longer than you’d like and money is starting to get tight ALL projects start to look good. Don’t take the project because you need the money. Take the project because it’s a good fit, it’s interesting work, and you think the client will be a good partner.
In the world of make-believe this is the way it should be. In the real-world you don’t always have those options. Plus, it’s really hard to figure out if a project is going to be a good one or not. Here are some of the red flags I’ve come to recognize in fifteen years of being a Xojo consultant.
Other Peoples Code (OPC). Code written by someone else is always a red flag. We write code a certain way and if any of our team work on it we can rest assured that certain things will be done (naming conventions, comments, etc.). No such guaranty with OPC. It’s way easier to start from scratch but with most OPC projects you don’t have that option. So you start with a level of uncertainty and having to decipher not only the coding style but often times the intent of another developer. Learning someone elses code stinks.
Project complexity. When I’m asked to join an existing project I try to look at how complex it is. If it’s really complex I hesitate because I know it will never get less complex. In many cases the original developer tried to be clever to solve some (real or imaginary) problem and while solving it completely overlooked a much simpler way of doing things. Plus, if it’s not one of your core competencies it might not be a good fit anyway.
Another item under the project complexity red flag is excessive amounts of documentation. From experience, most projects can be summed up with a page or two of high level description and then a dozen pages of important detail. When the client sends you a very long document with high levels of detail you might be getting yourself in other your head.
Of course the flip side of that is clients that send you a paragraph or two of their idea. In those cases we have to draw more information out of them, and depending upon the size of the project, we might actually charge them to write their specifications for them and let them get some competitive bids from other developers. I think the lack of detail says they haven’t done enough homework on what they want and need.
Toxic teams. Another issue with joining an existing project is trying to figure out if the team is toxic or not. The existing developers will always have their own habits and you, as the consultant, need to try and match theirs. What if those habits are silly? I’ve seen teams that require a comment for every line of code. I’ve seen some teams that disdain any comments under the guise that code should be ‘self commenting’. Is there a team member who’s the ‘smartest person in the room’ and everyone else has to put up with it?
Project savior. I can’t tell you how many times I’ve been asked to look at a project started by other developers and the project owner is desperate for it to get done. In these cases they’ve spent a LOT of money with a developer and gotten poor, or no, results. You have to ask yourself a few questions. Was it the developer being incompetent, the owner being unreasonable, or both? If you take one of these projects you can either be the hero by completing the project, or you can be the goat for being just as incompetent as the original developer.
Project owner/developers. I’ve found that working with project owners who are also part-time developers also can be a pain to work with, but not always. The ones that come to me realizing that creating an application isn’t easy and requires time they don’t have and knowledge they don’t have time to acquire tend to be okay. Those that say it should be ‘fast’ and ‘easy’ for someone with your skills have their expectations set too high. Software development, in many respects, is more art than science.
Always complains about cost. Every client wants their custom software done cheap, quick, and on time. The industry joke is to pick two of those qualities. Software development of custom software isn’t cheap, nor is it quick in most cases. If they balk at the initial estimate it probably won’t get any better. They certainly won’t like any change orders. We had one prospective client ask us three times, over the course of a year and a half, what the price was going to be to complete their project. I don’t know if they expected our price to go down, or what, but eventually they found a developer to do their project at the price they wanted. And then had the audacity to come back six months later then that developer couldn’t deliver.
Been through many developers. Perhaps my biggest red flag of them all is when someone comes to us after going through several other developers. Listen to their complaints about the other developers. Were they too slow, did they charge too much? I’ve even asked for permission to contact the previous developer to get the news from the developer perspective. The community is small so there’s a good chance I know them and I know I’ll get the developers perspective. Use those connections if you can because you might discover some useful information about the client and the project.
Just because you need the work doesn’t mean you should take every project that comes your way. Be selective because you’ll avoid some heartache and probably enjoy your work more. What red flags have you developed over the years?
