How to Develop Code Faster

February 28, 2007

First, we’re not really looking to develop “code” faster.  What we really want is to develop a “product” faster.  There is a big difference.  Largely that difference is that someone will buy a product, and they won’t necessarily buy code.  My goal is to maximize the amount of money I make compared to the effort it takes to produce it.  We’re looking for a local maximum in the relationship between the earnings curve and the effort curve.  Here’s the List so far:

  1. Get rid of Not Invented Here syndrome.  This is important.  Other people are out there writing code; some of them are even good at it.  They, too, are trying to sell a product.  If you have a common task, there is some code out there that will help you complete that task.  Basically, if you are building someone a CRUD app, then there is some code out there to help you.  Most people think it’s easier to write things from scratch than to use someone else’s code.  Please believe me when I say that you are flat out wrong for anything more than a trivial case.  Purchased applications have already been tested.  They have phantom unit tests (hopefully!) of which you are not aware.  Also, the code is being sold at a fraction of the cost that it takes to produce, because they are selling more copies they can afford to lower the price per unit when compared to the production costs.  It takes less time and resources to learn some 3rd party control than it does to implement that control yourself.  Yes, the control costs $450 or whatever, but you can pass that cost onto the customer, and they’ll be glad you do because you didn’t spend hundreds (thousands?) of hours implementing something that you could have bought for $450 and had working in your application in 2 hours.
  2. Learn the customer’s business.  This helps in two powerful ways. First, if you know their business you can speak to them in terms that they’ll understand.  They can speak to you in their own terms.  The removal of that communication barrier is a fantastic improvement to productivity.  You know what they want, even if they haven’t said it.  Second, in knowing their business, you know what they don’t need.  We think we are programmers, but we really should be sculptors.  Sculptors remove from a project until the project is perfect.  So too should we.  You can save yourself a lot of work, the customer a lot of money and both of you a lot of time by simply removing that which is not necessary.  This is the fastest way to get a particular feature completed, simply don’t do it.  Bam!  That’s off the list of things to do now.  Knowing the business is key to being able to make those judgment calls.  Stop doing unnecessary work.
  3. Code to a product.  Make your project meet the minimum standard that will fulfill the job that it will be used for. Coding to a product gives you a goal.  Goal galvanize great programmers to finish.  Measure your progress.  Do this only for yourself, doing it for anyone else is a waste of time because it is then subject to “gaming.”  The measurement can only be honest if you are doing it as a self imposed measure.  Pick a metric that gets you coding to a product.
  4. Rest.  Sleep.  Vacation.  Take two months off once you have put out that product that took 8 months to create.  Exercise.  Make sure you are taking care of your body.

That’s all I have folks.  The more I think about it, the more I realize that the best way to get something done isn’t in a framework or a programming language or an operating system (though these things help), it’s a social exercise between you and your customer.  This is why dog-fooding your own product works, because you are then your own customer.

Advertisements