Fighting Scope Creep

Software bloat is nothing new

Software bloat, scope creep, second system syndrome, whatever you call it’s the same thing. You are trying to make a piece of software do more than it was designed to. As a developer every line of code you write is making your software bigger. The good news bloat is controllable.

Think Small

Bloat will start creeping in the second you start thinking about a new piece of software. The possibilities are endless for what this brand new piece of software could do. That is the problem, when it’s new it could be anything. Too control bloat at this phase you need to start thinking about what the software won’t do. eliminate possibilities, and then start planning in those constraints. Set limits.

Cross that bridge when you come to it.

Once it goes from concept to design, this is where things begin to get dangerous. As you design the architecture, and implementation. You starting asking questions that start with ‘what if’. These what if questions have a tendency to get you thinking about the wrong problems. You may ask ‘what if we have 10,000 users will we need to scale?’ This is problem you can solve once you get there. ‘What if’s’ are like spiders, the big ones you see isn’t the one that bites you, it’s the small one, you didn’t see right under your nose.

Fight Like Hell

Users, and stakeholders will always have ideas of features that could help them, but it may have nothing to do with the system you are building, or it would distract from the core purpose of the software. Don’t include these issues, and create a backlog, and whatever you do don’t budge an inch. Being a jerk helps create a backlog of new features that users would like. This opens the opportunity for a dialog about what is important, and necessary, versus a ‘wouldn’t it be cool if’ or ‘I wish we could do this’ type issues.

Don’t keep picking at it.

During maintenance don’t rewrite or refactor code just because. If you do you will end up chasing windmills. Good is good until some one complains. You may have personal standards, but sometimes you have to let it go, to make money. Quality is important, but sometimes making something nicer is purely ornamental. If the code is horrible, the best thing you can do is comment it. Just let it go.

Get Disciplined

In the end it all comes down to discipline. Making something that is does what was designed to do. Examples of this were google, flikr, itunes / ipod. People like things that are designed well, but they also like things that just work. If you succuomb to bloat you end up with things such as MS Vista, Real Player, or Facebook. On a final note don’t try to please everyone you will fail miserably, if you make some inherintly useful, useable, and efficient people will use it if they have the choice.

Post a Comment

Your email is never shared. Required fields are marked *

*
*
Profile Picture

About Ian Lintner


I am a software developer, mostly web,  in Des Moines, Iowa. I take a very opinionated stand concerning development, you will never regret a simple design or architecture. My education was at Drake University in Biology and Computer Science. Offline I am recently married to my wife Heather. I try my hand at many hobbies currently I am gardening till the snow comes in.



My Current Projects


Des Moines Twitter Trends