Aaron Swartz has written up a guide for software development from idea to launch. He calls it “The Pokayoke Guide to Developing Software”. I was unfamiliar with the word “Pokayoke”, but it means mistake-proofing, i.e., “eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur”. Developing software from zero to use by actual customers is a huge endeavor and Aaron wants to ensure that mistakes don’t stop you before you get to your destination. Read the whole thing.
Here are some of my thoughts:
Completing a project successfully and completing a successful project are different things. You can write a great piece of software that functions well in all respects. You can also write one that is loved and used by many people. You have a lot of control over the former. Doing a good job of software development and avoiding mistakes will get you there under normal circumstances. But popularity is a tricky proposition. You can do stuff (market research, etc.) that gives you the illusion of control, but ultimately there are many factors outside your influence. Which is to say, that “need” is asymmetrical. If nobody needs your software, you are likely to be unsuccessful. But if you happen to find 20 people who need your software, it might just turn out they are half the world population that needs your software.
For a given need, there are many ideas that will fill the need. You could imagine, for example, some data-driven applications being replaced by a generic spreadsheet application. The key, of course, is to identify the need within the need that is causing all the trouble. Someone is worried about security. Someone about data consistency, integration with external sources, stupid-proof user interfaces and so on. The example of the iPhone is a little off therefore. You don’t normally set out to disrupt an entire industry. Typically, a common need is already being fulfilled (or in the process of) because it is common enough for other software creators to know about and act upon it. You would be extremely lucky to create an idea for a need that everyone has, but no one bothered to write software for. What happens usually is that there are some gaps where you can try to fill in with your idea. If you are fortunate, the idea could be revolutionary enough that people who already had their big need filled by the existing software feel that they need to have your solution.
I agree with Aaron that one has to look at the work of a programmer under non-stressful conditions to see what they are capable of. It is always useful if people can point to or send code that they have already written and then be able to explain why they did what they did. Sometimes a useful question, if you insist on having a programmer take a test in front of you, is what they would do differently if they had to write the code all over again. The key quality is to measure how much they are actively thinking versus how they are on auto-pilot. We all have both behaviors to some extent. When hiring, you need to go for the right mix. You don’t want an “yes-man”, but you also don’t want someone who is always changing their mind every day.
The “work with them” part of hiring can require care. It is easy to fall into the trap of looking for someone who is exactly like you in personality. One problem is the obvious: You would be hiring someone of your own gender, age, culture or racial makeup. The resultant lack of diversity is very risky because of the possibility of groupthink and lack of necessary competencies during an unexpected crisis. Avoiding this may mean hiring at least a few people who may have some personal qualities you have to tolerate more than you like. What I suspect Aaron was after with the “work with them” factor is the ability to easily communicate with them, i.e., the ability of someone to treat a spoken sentence literally instead of cooking up hidden meanings and doing something that was not intended.
Hypotheses should be resolved with data. In real life, people get emotional about choices in software. You also have the salesperson who is about to lose a big customer because the software team will not implement that feature that only this customer requires. Bringing the stakeholders to look at hard metrics is a big challenge, especially when money is on the line, time is short and passions are flying high. But it must be done and this is where good leadership comes in.
I am not an advocate of regular pair programming. If you have done a good job in hiring, it might be more efficient for programmers to work independently most of the time. Joint time will be more useful for discussing design approaches before coding, reviewing the code after the fact and eliminating hard-to-fix bugs. This is only my opinion, of course, but I think it stands to logic. You generally spend a lot of time in most projects writing banal code. If you are writing unit tests, the advantage of having another programmer look over your shoulder while you are writing such code is minimal.
As far as configuration management and deployment is concerned, the rule should be to keep it as simple as possible. Automate to make it simpler. Configuration management is a huge area that many software teams do not pay enough attention to, partly because some aspects are controlled by the IT team. But it can be the difference between well-done launches and nightmare releases that entirely disrupt the project plan.
