Making your development process suck less

One of the easiest ways to start an argument in developer circles is to propose making a change to the development process. The means of developing applications is so crucial to the process of developing software that everybody has an opinion, and they’re convinced that their right.

One company I worked for had a terribly dysfunctional development process. It started with the product manager (who was not technical) writing a spec. As developers, we’d ask technical questions about the spec, which would prompt changes to the spec. Of course, the deadline never changed. You can probably guess what happened with that deadline.

Even if your development process is completely broken, there are some things you can do to help slowly improve it.

Push for faster releases

One of the ways that you can be sure to deliver late software is by having a development cycle measured in months or quarters. A four-month project will almost surely be late. That’s not to say that a two-week project can’t also be late; it certainly can.

The advantage of a shorter development cycle is that you have a much clearer expectation of what you have to accomplish during the process. It’s much easier to say “I can do this in the next two weeks” and be right, than to say “I’ll do this over the next five months.”

The benefit that you can offer to the management is the fact that releases will come faster, easier, and with more predictable client features.

Estimate in hours, not in days, weeks or months

Smaller tasks are easier to estimate, period. It’s a core tenant of methodologies like scrum, to estimate in small hours and break down large tasks.

When someone asks you for an estimate, take the time to break it down and offer hours as an estimate. If they insist on an estimate without giving you the time to do it properly, refuse. Remember, an estimate is a “best guess”, but you’re going to be held to the number you give even if you’re wrong. So don’t put yourself in that position.

Make releasing your software easier

How many steps does it take to ship a release of your software? Is it a one-step process? Is it automated?

An automated process for packaging and shipping your code will make it easier to do, which will make your development process easier. Why? Because you’ll be in a much better position to push out fixes and ship changes without the hassle of the long manual process you might otherwise be required to accomplish.

How can you convince your boss that this is a good idea? Same way you can convince him to release faster: getting things done.

How do you make your development process better?

~ Brandon

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Greg wrote at 10/4/2014 5:37 pm:

“Smaller tasks are easier to estimate, period. It’s a core tenant of methodologies like scrum, to estimate in small hours and break down large tasks.”

You should actually not estimate in a time period at all. Relative estimating is shown to be vastly superior, for a number of reasons.

Firstly, it’s far easier/more accurate to say “X is twice as big as Y”.

Secondly, it decouples you from stakeholder expectation of time. If you say “I can do this in 2 hours”, there is often a false expectation that it will be done in 2 hours – not that it will take 2 hours of expended effort.

Finally, hours represent how long 1 individual in a team will take to complete an item, but it doesn’t account for how long it will take another individual in the same team. It will always be “twice as big” relative to Y, but points based estimation accounts for the fact that Dev A takes 2hrs and Dev B takes 5hrs. As a team you can quickly figure out how many total points your **team** is capable of delivering.

Copyright © 2023 by Brandon Savage. All rights reserved.