Software development can be a joy

Historically, software has not been fun to create

Bugs.  Delays.  Budget overruns.  Extended, extremely details plans.  Miscommunication.

Bugs

Hey, the exist.  But they don’t have to paralyze and bog down a project.  The solution is Behavior driven development where the feature descriptions becomes tests first, code second.

What this does is catches many bugs immediately–it turns out that adding that new feature, actually broke another feature, and your automatic collection of feature tests caught the bug instantly.

Delays

Delays can happen.  But they can be controlled by client/developer communication and web-based project software.  Imagine being able to 1) logon to a program that has all the completed, in progress, and not started features; with a forecast of completion for all the scheduled features (given the current pace of work).  Pivotal Tracker.

And, how cool would it be to using a working edition of your software as it gets developed, as opposed to waiting until 1-week before launch to use the software?  Weekly releases.

Budget overruns

Stink.  And they are still possible, no matter how good your development team because every software project is seeking to solve a new problem because otherwise you would just buy completed software.
Budget overruns can be contained by getting a fixed quote, and handling new feature changes that come once the project has started by substituting out old, un-developed features for the new feature.

Extended, extremely detailed plans.

These are very common in software development–every single button, letter and feature is diagrammed and described in a process that takes longer than 1 week.
There are two problems with this:  one, with that detailed of a plan, no one wants to change anything until the project is finished, often 9-18 months later, when it turns out that talking about the software on paper couldn’t discover everything the software needed to do until people were using the real thing AND business needs have changed in the time since the plan was finished and later when the software was finished.

Then future delays could be seen coming, and adjustments made to the scope, speed

Imagine writing a novel where you wrote out all the requirements, and turned them into tests that were run every time your changed something the novel.  1) It must be less than 30,000 words, it must create suspense, it must involve father-son conflict, it must involve a trip to Nashville

Miscommunication

This will happen on a software project, but it can be less painful.  The most painful miscommunication comes from clients and developers expressing their ideas, even on paper, but waiting too long to see the real software in use.

Example:  client-I want a blog with comments; the developer spends $3,000 building a blog; but when the client sees it he realizes only one user can update it, and it doesn’t save drafts, but now it’s too late and the deadline is here.

This can be reduced by transparent project management like Pivotal Tracker, where all the features can be seen, with their completion or inprogress status.

It can also be reduced by you, the client, having a working version that you can use as it gets developed.

Misunderstandings can be cleared up a lot sooner by having working software released on short intervals, as opposed to having months between new editions during development.

What I want for you, if we work together, is a new feeling about building software–this doesn’t have to be painful.  It’s kinda fun.  I’ve got some more ideas for web projects to do.  I think I’d like to work with someone like you for a long time.

Comments are closed.