Posts tagged as:

process

never rewrite your software

by Andrew on July 1, 2008

All software is a work in progress none is ever perfect. It will always have bugs, sometimes it might even seem that the software is nothing but bugs an it’s in these dark times when we normally say fuck it, let’s start over. Not always, some of the good excuses I hear for a rewrite are:

  • New blood Someone new comes along and the first thing they suggest is a complete rewrite - It’s alarming the number of times I hear this suggested. Sometimes it’s contractors, which is somewhat exusable - it’s more billable time for them. Other times it’s by people newly in charge or new to the team.

  • Team members have left - rightly or wrongly they’ve been blamed for the code, and coding them out seems like a good idea

  • Too many bugs - An effort to hammer out the bugs feels like it would take longer than to rewrite from the ground up

  • New tools! - A shiny new framework is out and you want to use it, it will solve all your problems and put all your spare cycles to work sorting out poverty and war.

Common to all the above is the fact that everything seems like it would be easier if only you could get out from under the crushing weight of legacy. And it’s a very attractive fallacy; Bugs could be solved by reworking the architecture; Features would be easier if only the code wasn’t written that way; That new framework would fix the bugs we’re seeing because of the one we’re using.

resist the temptation

They sound like good reasons, but that’s the problem with attractive things that are bad for us - they’re attractive. It’s so much easier to believe that the grass would be greener if we re-turfed the lawn than to work out how to fix those brown patches.

it almost always takes longer than you expect

A complete from the ground up rewrite will take longer than you think. It will probably take almost as long as it took you to get where you are now. It’s tempting to believe that you don’t need planning meetings to work out what has to be done. It’s right there a spec in the current implantation, just get started! So you’re initial estimate is just a stab in the dark anyway.

Add to this the further false belief that since you implemented the features once already, you’ll be able to do it faster this time around. You won’t, well you might - but you won’t implement them as optimistically quick as you think you will.

Throughout the process you’ll also be further from a releasable product than you think you are - much further. In a rewrite you have to rewrite every feature all those “all we have left in component x to do is…” bullet points add up.

All of this leads to one last problem with timescales for rewrites - in order to get anyone else to buy into them they have to be wildly optimistic about the schedule. So just when you need everyone most motivated and excited, as you’re gearing up for a release, you’ve set them up to be demoralised by missing an increasing number of deadlines.

you’re reinventing the [buggy] wheel

Programmers are people, people are creatures of habit. You’ll inevitably end up implementing part of your radical new system in a very similar way to your existing system. Then you’ll be forced to make the same compromises as you’ve made before and you’ll undoubtedly introduce some bug that’s already been patched in your existing software.

Some of your old code will also be good code, at best you might cut and paste it into the new code base but for the most part though trying to hammer it into place and wire it up is going to be as long and as buggy a process as rewriting it. So instead you follow the rewrite it all logic and rewrite it all.

you’re standing still

When you’re rewriting your software you’re stainding still in almost every way possible. If you’re rewriting everything, you’re spending an awful amount of time not moving your application or business forward. Personally and professionally you’re not learning much new (unless a new framework is your excuse).

Even if you’re squeezing some features into your rewrite, probably because it’s been so long since a release you’d be lynched by a mob if you refused, it’s so long before the users are actually going to see them that you might as well not be. The perception of your software isn’t going to be sometimes shaky, but getting better all the time - it’s going to that it’s buggy and the bugs are never fixed.

you’ll probably end up no better off

The sad and somewhat painful truth is if a team can’t fix something - getting them to make a new one is probably not going to fare much better. Your new version is probably going to be no better than the old, will certainly be worse than an itteratively developed and incrementally improved version of what you had could have accomplished in the same time.

Also problems you’re having with a framework or tool probably aren’t going to be magically solved by using a new one. Most of the these arguments are born out of a naive belief that because the framework isn’t doing what the developer is expecting, the framework has bugs, changing frameworks should then solve the bugs. The problem is of course developer expectation versus reality and more often than not due to some underlying misunderstanding of the platform the framework or tool is abstracting - a reality that a new framework cannot change.

how to sensibly go about a whole rewrite of your software

While it’s not sensible to start a full rewrite of your software, it’s also ludicrous to decide that nothing written should be changed. Software development is a process not an event. If it’s not working fix it; if it’s complicated and bug prone, refactor it; if it’s shit, code it out. Just don’t throw the good out with the bad.

Start where it hurts

In the case of bug riddled software start with an area that is causing the most trouble. Patch the big bugs first. It can be a painful process, I won’t lie. It’s demoralising to everyone to have buggy software and it’s not exciting or glamorous to fix it.

Bug fixes are one of the most thankless tasks developers are asked to perform, so make sure you break it up with some of more challenging and interesting tasks, throw a few features into each iteration.

if I could do it all over I’d change…

These are the generally the things that are hurting the developers rather than the user. Some of them are far reaching, architectural or framework choices. They can all be fixed though, and you don’t need to rewrite the whole application to get there.

Again, start with the ones that hurt the most, if it’s part of the architecture refactor it. If it’s a framework you’d like to integrate to solve problems, try it out on part of the code and work to roll it out incrementally.

I promise it will be quicker, a lot quicker to go down the incremental route than it will be to rewrite the whole thing in one go.

{ Comments }

It’s not working! Again!

by Andrew on June 27, 2008

Bugs, in an awful lot of organisations they’re a four letter word, they just shouldn’t happen. But unfortunately despite the shouting and stomping, they still will.

your software has bugs

Your software has bugs, go ahead, say it, try it on. Does it scare you? It doesn’t scare me. I know mine does, this isn’t a shock, revelation or epiphany for me. I had that years ago:

One dark stormy night with a start I sat bolt upright and realised I wasn’t perfect, that I couldn’t write perfect code. I sat through the rain and the thunder awake and frightened, but as the sun broke the next morning it a clear new day dawned on a world washed free of it’s sins. I felt renewed, rejuvenated; I bounded to the office, spearheaded an overhaul of our development process, got a more agile workflow implemented with fast iterations and complete management support.

Ok, it wasn’t quite like that. I was actually up all night because someone somewhere had been freaking out about yet another bug the day before. It was affecting one user, and it would only be a matter of time before it would be affecting others - then like dominoes all of them; soon they’d be the rats leaving our sinking ship upstream and they’d take the paddles with them - in short: DOOM!

It’s very easy to find a bug, say it’s obvious and should have been tested, it’s quite another to test all the functionality and find all of the bugs before launch. My software has bugs, so does yours and everyone else too.

get over it and stop blaming others for your problems

Bugs are a result of code, written by programmers- but it’s not always just the programmers who are to blame. Organisational pressures leading to scope and feature creep, poor design and processes or a lack of any sort of roadmap will all contribute to the problem.

So many times I’ve been working to a deadline (beginning, middle or end - it doesn’t really matter once a timeline is fixed any changes will incur a cost), then someone comes along and starts a sentence with “What about…” and totally blows the schedule. The problem is people rarely take into account the very simple fact that the schedule wasn’t set to include this new task, or the next next one.

This schedule pressure then leads to rushing either the design, the testing, the coding or all of them - this more or less ensures there will be more bugs.

Common excuses I hear for this are:

  • It’s obvious, and should have been thought of. Sometimes this is a valid comment, but I have never been part of a team where the obvious was actually missed. In my experience this has almost always been used as some rhetorical comment to excuse someone for not mentioning a feature until launch or later.

  • If we don’t have that for Friday’s launch, we won’t get customer X< The short simple answer should always be, if this goes into the current iteration- no customers will get a launch Friday.

  • Adding would mean getting so many more customers This is such a great trap for a business- so good I’ll be writing much more about it in the future. Oftentimes it’s political or the result of an organisation without any clear goal setting or planning.

Schedule pressure is often further exacerbated by not making any allowances for bugs. If you don’t make allowances for fixing them post launch, you’ve already missed your next deadline.

what can we actually do about them?

There are a few things we can do organisationally and individually to lessen their impact. Start by not being afraid of them, accept they’re a fact of life and get over it. Shit happens, and it piles up - get a shovel or get out of the way. Look to the processes and people and streamline the development workflow. Everyone involved needs to think things through. Finally once you’ve accepted bugs, worked to minimised them in development deal with them calmly and rationally, if at all.

deal with the workflow issues

If your development processes seem to be creating a lot of bugs, they’re the fist place to look. These are going to be the hardest to change, but they’ll also give you the biggest returns. A few of simple steps to take:

  • Design the interfaces first Changes to desgin mid-stream cost at any stage of the cycle, but the earlier they’re discovered the less of an impact it will have. At least wireframing your interfaces means everyone gets a good look at them before development starts, and can say “what about…” early.

  • Remember changes cost When someone asks for a change, make sure you point out that changes will affect delivery. Ask them why it wasn’t thought of earlier. Don’t take anything as read and make sure nobody else does either.

  • Iterate often Small quick iterations mean features go into use quickly and mean less changed code and less places for bugs to hide. This also allows bugs to form part of the next iterations work.

all bugs are not created equal

Not all bugs will affect people equally. Minor display issues are not as important as an issue where user data is randomly disappearing. An issue where the front page of your website is full of gibberish is far more important that a newsletter not being sent on time.

All bugs should enter a triage system, where the scope of the problem is analysed and a prioritisation decision is taken. There is no room for rhetoric, blame or politics in this process and clear descriptions of the problems are key. The title of this post is verbatim the subject line from quite a few emails I’ve seen in my life, the body is usually not much more helpful and generally descends into politics and conflict. A minor display issue affecting some users is hardly “irreparably damaging”, “actionable”, cause for anyone to “seek any and all legal recourses for reimbursement or compensation” or cause to run off and offer the person our most heart felt and abject apologies for the inconvenience.

We need to step back, look at the extent of the problem and respond appropriately. Going off on one while a wild wacky tale to tell alter, isn’t really professional or productive.

Which leads us to…

not all bugs need to be fixed immediately, or even at all

In a perfect world, we’d fix every bug as soon as it was reported. Then again, the world wouldn’t be so perfect because we’ve got a bug in our code… in a slightly more perfect, yet undeniably imperfect world we’d like to fix bugs as soon as they happen. This isn’t always going to be possible and for various reasons it may not make sense to fix a bug immediately.

Take for example the following completely hypothetical situation. You’ve got a bug in some obscure import routine written for one customer a year and a half ago. The sales team promised it was going to be the next big thing, would open the door on a whole raft of customers that used that package - it turned out to be just the one and they may or may not renew their contract in six months time. Politics aside, given certain situations the import fails and you might choose to just not fix the bug

  • They’re unlikely to renew and fixing it isn’t going to sway them or get you any new customers Don’t fix it and just remove the whole broken import from a future iteration. Chalk it up to learning and plan new features better so you’re addressing the needs of your users

  • A work around exists Your time might be better spent elsewhere, especially if the problem only affects a single or small number of customers

  • Planned developments will obsolete the feature A reworking of the feature, section or other areas of your website, the integration of a new API or a new workflow or way of doing things may mean the bug just dissapears in a future revision. One caution with this, as with any bug fix the promise should be delivered to the cusqtomer on time

{ Comments }

Newer Entries →