The shortest path takes too long to find

At first I named this blog Shortest Path, but I quickly realized that I am not oriented around finding the shortest path. The shortest path can often take too long to find, and often it isn't very fun getting there. I think there are lots of examples in modern software development philosophies that ring true to this idea.

Premature Optimization, why is this generally held as a bad idea? Because the art of software development is complex, and we just don't know where we are going to end up at the end of the day. A great deal, maybe even a majority, of features that are added to applications either never get used by customers or worse never even make it into the product. So until you know that performance is a problem in your code and until you know that people will use it, don't bother. It is likely to be a waste of time and attention. Choose the short path, finish the feature and move on.

Premature Feature Building, I think I touched on this above but I think this deserves its out shout out. More and more the successful software companies are building for people, and they include those people in the process of development. In Extreme Programming this is evident in the rule of having a customer as part of your development process. This is because more often than not your customer does not really even know what they want, and you as a developer or entrepreneur certainly don't know. So, instead of guessing, start small. Build out the minimal amount of features to get someone's attention. If you can't get their attention then iterate until you find a way to get their attention. Adding features is not a way to get someones attention, it may be a way to keep their attention for a while longer, but you won't get them to stay by giving them a long list of things that they could do with your software. Take the short path, you might end up building all the same features but do it from a place of informed strength.

Test Driven Development, this is the best example of the difference between finding the shortest path and taking the short path. The shortest path would dictate the you always achieve complete code coverage with your tests. Some people even advocate throwing complete garbage at your code, or mixing up the decision tree to see that everything breaks in the correct way. It is believed that if you do this you will greatly accelerate your teams development because they will have a safety net of tests to protect them from lengthy bug cycles near the end of a release. I do believe that the tenets here are true, but I don't do it. I don't do it because it take a lot of attention to build out these test suites and keep them current. I think that the real advantage of writing tests is that it allows you to focus your attention on the specific problem that you are working through. Once you have tamed the problem, move on, take the short path. If you spend a couple more days getting code coverage you will probably find that in a week the features have changed or that entire business unit has closed down.