I will often compare dealing with a software company to buying a house. They are both costly enterprises that have to be viewed as a long-term investment and can both bite you back if you unknowingly buy a lesser product. Hidden defects I think they are called.
Sure, that roof might look pretty decent, but look under it and you realize, the previous team that worked on it simply added a new layer of slates and called it a day, leaving the old, decaying roof under this visually perfect roof. A great illusion which, as I previously mentioned, can also work in the world of software and web development. It can be the case that a website looks just fine, great even, but underneath is a mess of unmanageable code and this matters because you will start losing money on your investment as soon as you want to add something on your website.
In short, just like a house or a car, you need to really take the time to shop for your developer.
OK, yes, that is easier said than done considering it’s a pretty unknown and very technical domain, but that’s where this post comes in. I’m going to try and give you a few tips on how to decide if you should do business with a given development company or not. Now, of course, those are not the “THREE QUESTIONS THAT WILL REVEAL EVERYTHING TO YOU. YOU WON’T BELIEVE WHAT NUMBER 2 IS” (I hope BuzzFeed doesn’t sue us). They are guidelines, but more than that, they are my opinion. I will also remind you that not every project has the same needs, I previously wrote about this in Your project will evolve, even if it doesn’t (what a shameless plug and horrible title in retrospect).
Be Wary of Those Who Aren’t Scared of Big Projects
If the words “I want to build Facebook 2” does not scare the developer you’re talking to, he should not be considered at all for your project.
It’s easy to create this very big software that barely works, with a crappy architecture under the hood. Then one year down the line you want a feature added and suddenly you can’t because the software is so brittle your developer has nightmares when he goes to bed. Remember the crappy roof from earlier?
Every developer who has actually built a big software will know what it implies, the complexities and the money that goes behind it. Even simple projects can easily get really complex, really fast. Because of this, I suggest you try and be aware of the reaction your developer has when you suggest a new project. I always try and speak with my client when they propose a new project; about the features they want, their utility to the project, what is the version one, do they really need that many features to start with, etc. I will always ask those questions. I’ve done big projects in the past and I’m not afraid to tackle those anymore, but I do value my client’s satisfaction, his return on investment and the part of my job that says I need to also try and educate my client about the real complexities of the development world. Those are things you should be on the lookout for when pitching a project.
The key here is I’m not questioning my client because I don’t want to do their project, I do it to make sure everyone realizes the amplitude of a given idea and is on board. I would argue this is a sign of someone having worked with those kinds of projects before and that values ethical and professional work. Which are good things you should be looking for in a developer.
Appreciate the Technobabble
I know it’s irritating, of course it is with a silly name like that. I still think you need to appreciate it, if only because it gives hints that maybe, just maybe, this guy knows what he’s talking about. Obviously you won’t understand this kind of speech, but that’s exactly why technobabble is great: you get to ask him to explain what he just said.
At this point you don’t really care about what he’s saying though, what you want to do is evaluate his confidence as he’s explaining all this tech speak he just released on to you. What you’re looking for is his confidence in his knowledge, you want to make sure that when he says buzzwords like Isomorphic app, he actually knows what he’s saying. Like Albert Einstein said, “If you can’t explain it to a six year old, you don’t understand it yourself.” Plus being questioned always gives you that additional stress which is excellent to evaluate someone’s knowledge on a subject.
It is far from a foolproof method, but it’s an additional tool you can use to evaluate a potential developer.
Maybe it’s just me, but I can’t stand people who are so afraid to look like fools, rather than admit they don’t know or remember something they will simply make up an explanation on the spot. This is also extremely scary in a developer. It makes them say “yes,” when in reality they should say, “let me get back to you on that.” That’s not too bad, they can always come back and rectify their answer you say? Well, yeah I suppose, but really though, they probably won’t. They were too prideful to say they didn’t know at first, do we really believe their pride will not stop them from coming back on the answer they gave?
It sucks when you’re waiting on an answer. However it should be celebrated when a developer asks you to wait a bit; it means he’s willing to research a bit before promising you the world. This is invaluable in a programmer. Programmers want to do it all. We want to make that awesome app with fancy animations and this incredible feature set. When we say we’ll get back to you, we’re making a really big effort not to just say yes and start coding right away. The problem is we often want to code before we even know how things are going to work or if we even have the skills to do it!
For this reason, the words “I’ll get back to you on that” are proof that the person you’re talking to is modest enough to admit they don’t have the answer right now and this is something to be desired in a developer. They will also not waste your money by rushing into things without stopping and thinking about the feasibility of a project. Not wasting money is a good thing, right?
They Should Want to Talk With You
Whenever someone calls Solution Majisti, we pick up the phone and we’ll listen and talk with them. When our clients ask for a long call to talk about x features or y project, we pick up the phone and listen. Those calls sometimes get derailed, jokes and stories and such. That’s all good; we want to talk with potential clients or current clients. The more we talk with them, the more we know the kind of person they are and the kind of business they run and this in turn helps us guide them better. The truth is we don’t know how businesses , others than ours, run and this is a vital thing to be aware of when developing a product. You need to know how it will be used.
“How does this get me a better developer?”, I can already hear you say. Well, it’s a bit abstract, but to me (and many other developers I have spoken to) it’s a sign of a caring developer. One who wants the best for your product, one whose passion makes it so he wants you to be satisfied with his work. Note that I don’t talk about skill here, but passion and care.
It’s often a forgotten value when looking for a development company, but if they do care about your product and your business, you will often get a lot more value out of them; be it by better focusing your investments, better understanding your needs or simply by taking the time to talk to you about problems they noticed instead of staying silent about them.
Obviously not. Skill level is also a factor, but there’s no easy way to know this without digging in their code and I doubt that’s something you want to do. There is also a million other factors that will determine if a developer is a good fit for you and your business; those four things I mentioned are however good signs to look for when trying to find someone to build software for you.
Ultimately though, it’s always a bit of a gamble. Sometimes it’s not even about competence, some businesses just don’t fit well together. Solutions Majisti could be the right fit for you, it could be the worst. Different businesses have different needs, but I hope this is at least going to help you skip the obvious bad fits.