Well, it was past time for another redesign; so here it is. Notice that I said redesign rather than tweak. With your periodical design tweak, you take every thing down from the shelves and dust. Maybe, if you’re feeling frisky, you shampoo the carpet, or you try that new image replacement technique those hipster Ajax kids keep harping on about. What you don’t do is tear off the entire roof and replace it with it pneumatically raised, mechanically articulated, alfresco disco floor.

That you save for the full redesign.

But the full redesign is more than just a chance to knock out a few walls. It’s a chance to think about whether you even need walls. When you start you think: “Why, of course I need walls! How else would my roof stay up?”. But there are other ways to hold up a roof, ways that are distinctly unwall-like. Hell, maybe we don’t need a roof either?

The nice thing about doing a full redesign is that the whole process can be rather a good excuse to get quite Meta about things. You get to think about your motivations and processes; you get a chance to make dramatic changes. The kind of changes that will almost certainly be challenging, a little painful, but also completely invigorating. If your redesign isn’t these three things (and a whole lot more) then you’re likely doing it wrong.

I’m not talking about the kind of wrong that will cause the police to kick down your door. No one’s going to drag you out of your house, throw you in front of the camera-flash happy media and accuse you of laziness. Instead you’ll miss out in lots of small, quiet ways. Ways that don’t seem important in the short term but, from the perspective of a longer timeline, may be the highlights that define you.

So you embrace change and throw yourself into your redesign. You learn, grow, and come to a better understanding of how you work and think. Is there any particular reason that you couldn’t do all of this as part of a smaller design tweak? Yes, absolutely, and you should. But you miss out on the context switch.

The Mighty Context Switch

I’m always amazed at how many difficult problems become tractable, or even trivial, from a different perspective. Sometimes all that’s needed is a different context and, hallelujah, the hidden path becomes visible. I always assumed it had something to do with the cognitive load that a particular context puts on a person, that is: the sheer amount of junk you need to keep in your head to understand what’s going on in a large project.

Context, constraints, and history are all bound up tightly together. When you’re managing a project you try your best to not let that bundle become an angry, knotted mess. If you don’t, you won’t get to spend your time creating. Instead you’ll spend your time nervously pulling on exposed loops, hoping that each one you tug on isn’t the one that leaves you with something that you’ll never untie.

Striking the right balance is hard. I have infinite respect for the few project leaders that I know can manage it. You want to acknowledge context (otherwise what you deliver would serve no one) and you want to embrace your constraints (so you’ll be making the best use of your resources and avoiding undue effort). But you also don’t want to be held hostage by your constraints and history; You want to be agile so you can respond to new situations.

This is not the same as the Project Triangle (TL;DR Version: Good, Fast, or Cheap. Pick any two). In fact context, constraints, and history are three of the most critical things to take into account when pondering your own Project Triangle. Sadly, there isn’t a nice clean mapping between the two. Instead you use them (and other factors) to work out what Good, Fast, and Cheap would look like for your project — and what the relative cost of each would be.

Constraints are Liberating?

Constraints are definitely Liberating. That has definitely been my experience so I don’t want to imply otherwise, but there’s usually a point in every project at which the choices that you’ve made are too hard to undo — your constraints too limiting. This is when you have no choice but to step outside of your project’s context. This is also usually the point when, right or wrong, people start talking about a redesign.

It’s tricky to know when a full redesign is needed and when a few tweaks are all that’s needed. I don’t want to give the impression that a redesign is all ponies and unicorns. On large projects deciding to do The Big Rewrite is a decision that can, and frequently does, kill a project. They are dangerous for a great many reasons, and really are the atom bombs of project management. Even if it solves your problems you might not be able to live with the consequences.

Neither the High Road or the Low Road

There is definitely a middle path that can be walked. A place where you gain a number of the benefits of the redesign, without having to accept all the risks. That is the Incremental Redesign. The Incremental Redesign is exactly what it sounds like: you take your one large redesign and divide it up into a series of smaller, discreet projects. The discreetness of these projects is actually the secret sauce that makes this work, as it allows you to tackle small chunks of the problem without being forced to deal with the complexity of the entire project.

When done right, this allows improvements to be deployed to a specific part of a larger system without major interruptions to overall system availability. This means more frequent deploys, faster feedback cycles and (usually) a system that zeroes-in quicker on the user’s needs.

A particular challenge when attempting this is dealing with systems that have degenerated into Big Balls of Mud. I’m hard-pressed to characterise this as a flaw of Incremental Redesigns, as systems in this state are always a complete pain in the arse.

Seriously, expect to loose both hair and sanity.

Replacing them in a single massive redesign is hugely risky, but it can be equally difficult to identify subsystems modular enough that they can be tackled without accidentally borking related systems. Usually a process of partial decoupling will be necessary before the real redesign begins. This is frequently painful both technically and politically as your users frequently won’t see any immediate benefits of this work, so you need to work harder to justify it to the stakeholders.

In large systems that are critical parts of businesses infrastructure, there is a (correct) instinct to be constantly improving. Your best shot at this is by bringing the capabilities and purpose of the system inline with its users and the overall objectives of the business. This all becomes a bit like painting the Forth Bridge (interestingly enough I probably won’t get to use this phrase anymore), as the user requirements will be constantly evolving, as will the businesses, so systems are never really finished.

There is a tendency, particularly for badly briefed CFOs, to view this as something of an indulgence. But if you’re a company that leans heavily on a piece of technology that you support internally, then you should be viewing this as a necessary investment to stay competitive and an opportunity to develop these systems in such a way that they can actually make your processes more efficient.

But this only works if the purpose of these systems stays relevant to what the business is trying to achieve. If you redesign once every couple of years then it’s nigh-on impossible to do. If you’re constantly analysing and improving your systems, then it’s only bloody hard to do.

These goals gel really nicely with the idea of a continuous, Incremental Redesign. In fact, I’d go as far as saying that this should be the default way of approaching long term development on software projects that businesses have a stake in.

This sure is a lot of words

Yeah, it is. Especially since I could have just gone with: Here’s my new site, enjoy!

One of my goals for the redesign of this site was to give myself a vehicle to jot down a few thoughts about how I do things. This definitely isn’t self-aggrandizing, nor is it a marketing exercise. I’m not a writer and, I dare-say, I’ll embarrass myself more often than not. But I totally buy into the idea that you show/gain mastery of a topic by explaining it, and frequently the best way to communicate something is still to write it down.

My whole spiel about redesigns came about because it was already on my mind. This was partly because I needed to bring luma.co.nz inline with where my head was at, but it was mostly because the issues of design, redesign, and maintenance are very relevant to most businesses I deal with.

It’s a sad fact that most businesses still have a very uneasy relationship with software. This is especially true for companies that develop or maintain software, but don’t have software development as part of their core business. There really is room for us all to improve here. But I figure it will only get better if we’re actually discussing these issues.

To put it another way, it was time that I joined the rest of the Internet monkeys and see if we can’t bang out the software engineering equivalent of Shakespeare.