c o d i n g f r o g s

croaking about programming, programming languages, software engineering, and the business of software

5Feb/100

Getting Coders to Code

Think back over the last project you worked on and the time it took to complete it.  How was that time spent?

At first glance you might come up with a list like this (in no particular order):

  • Gathering requirements
  • Designing
  • Implementing
  • Testing

Think about it harder, though, and you might come up with a number of additional things:

  • Sitting in meetings
  • Waiting for people to review and approve your documents
  • Waiting for people to finish reviewing your code
  • Reviewing other people's code and documents
  • Setting up dev and test environments
  • Dividing your logical tasks into smaller, sometimes illogical units for the purpose of tracking
  • Entering tasks into an issue tracking system
  • Documenting and updating status on assignments
  • Reporting status to management
  • Branching and merging
  • Fixing bugs
  • Reading e-mail
  • Administrative and red-tape

Now, go through the list you have.  Which one item are the customers actually paying for?

That's pretty easy — the implementation.  Ultimately, what the customer is paying for is for you to write code.

This begs the following question:  If writing code is what customers are paying for, why is so much time spent doing the other stuff?

Your knee-jerk reaction would probably be that all the other stuff helps you to do your job better.  Generally, I'd agree that most of those other items CAN help you do your job better, but I'm going to challenge the reason why you are doing them.

Writing code is the primary activity of a software development team.  To be more specific, writing correct code should be the primary activity of a software development team.  Given a specific feature that customers will pay for, every correct line of code written for that feature directly contributes to revenue.

Therefore, in order to maximize revenue, your goals should be to:

  • Maximize the amount of time that your developers can be writing code
  • Optimize that time by improving the likelihood of each line of code being correct

Seems pretty simple, right?

Now, take a look at the way you conduct your work.  Ask yourself this question:  How would your work change if the focus was to spend as much time coding as possible, and to improve the correctness of each line of code?

Would you change the way you do your work?  If so, why are you working that way?

blog comments powered by Disqus