This first post is not going to be a cheery “hello, world”. I’m not a blogger. I’m not going to introduce myself. This is just yet another blog, and you know what to do with a blog, so just do it. This post is about the second system effect.
Many a year ago, somewhere around the start of my career, I read the book The Mythical Man-Month by Frederick Brooks. If you create software, in any form of it, you should have read this. There’s no point in explaining why, and I’m not here to sell the book — if you love your profession, read it.
Brooks devotes five pages of the book to the phenomenon of the second system. That’s a bit too much really; for the concept of the second system is something simple and so fundamentally human, that it can be understood by just a few paragraphs, maybe even a blog post. Why it is so interesting, however, is its omnipresence in just about all aspects of software development.
Consider: a person develops a software. A tool, let’s say, that solves a problem faced by his team daily. He shows it to his colleagues. They like it. They love the fact that it saves them time and effort. They’ve a few suggestions, however. A few things that’d make it more convenient for them. Sure, says the developer, happy to help. He realizes some very cool and helpful features cannot be added without changing basic assumptions and algorithms in the code. So those features will have to wait.
Days go by. The software is a hit. The developer has incorporated quite a few suggestions from his happy users. There are some cool features, however, that’d make it really a blockbuster. It’d take time though, since the core design will have to be changed substantially to implement these. He realizes how the design should have been in the first place — more general, more flexible, like this, not like that, use this, not that. The scribbles on napkins and doodles on whiteboard develop into UML diagrams. He researches similar tools offered by others, and realizes that with the new features his software would simply be the best in the market.
It’s not easy, he realizes. He shouldn’t really have had to do this, if the original design was more open and flexible. And more generalized. Backends, what about backends — of course, it should be able to work with any database! Yes, that’s what has to be done. Quite generic, of course. That’s how it should have been, always.
Most of the old code was thrown away, since they couldn’t be refactored into the new design, or had assumptions that tied to specific systems and situations. His faithful colleagues still used the old software, however, since it solved many of their problems. The developer worked all his spare time on building the second system.
Stop.
At this point, the tired architect would like to interrupt the gentle reader. Because the story does not end here, or ever. The building of the second system goes on. And on, and on. Until they’re forcibly put to death by emptied budgets, tired management, or burned-out developers. Second systems are tempting visions painted by the devil himself, take the path and you’ll find yourself in purgatory sooner or later.
The second system originates from a deep, basic need of humans — to make things better. To correct mistakes. To live life one more time, without making the same mistakes again. The Undo button. Do it till you get it right. Citius, Altius, Fortius.
The second system is not a disease, it is a symptom. Which indicates that the people involved have not worked on a second system, or are not aware of what is the second system.
If you haven’t worked on a second system, you just can’t appreciate it. As they say, good judgement comes from experience, and experience from bad judgement. It makes you a better architect, like how pain makes you appreciate health better.
Look around your world today — do you see people engaged in second systems? People trying to build the “next version” of their software that will be the “biggest and most light-trippin’-fantastic” ever? Versions that keep on getting written? Rewritten? Refactored? People trying to create their own software that will solve all the problems of the previous one? Programming languages? Web frameworks? IDEs?
If you haven’t been there, be aware enough to catch yourself from falling into the trap. Good luck.
cumpsd said,
Oct 22, 2007 at 2:11 pm
Nice explanation! I’ve been involved in quite a few of second systems on my personal spare time, always due to being too perfectionist. And burn-out was usually the result after a while, making me work on a slower pace for a while, till the fire got lit again and the energy was back at full force.
But, as you say, it’s such a strong need.
Maik said,
Oct 25, 2007 at 1:04 pm
Sorry, but I don’t believe this blog post amounts to much. Software development is much too complex for simple concepts like “second systems are evil”. Often they are, sometimes it works and results in a better piece of software, sometimes they are absolutely necessary. It depends on countless factors. Would we know the name “Firefox” today if it hadn’t been a complete “second system”? WHY the hell do developers work in their free time on the “second system” at all? You say so yourself. Doing something from scratch is highly motivating, it’s like cleaning up your desk and getting a fresh start. You can try out new things you’ve learned, new concepts that evolved in your mind. Programming is all about motivation, about passion. Every one should have a “second system”.
The real factor leading to burn out and “emptied budgets” is not tighly controlled, incremental “seconds systems”. It’s feature creep, a very common and totally orthogonal concept. You can have feature creep with legacy software too. This has nothing to do with refactoring or rewriting at all. Feature creep happens when you don’t set specific goals and concentrate on getting usable versions out of the door in short intervals.
Riccardo said,
Oct 25, 2007 at 1:06 pm
Hello,
actually I’m working on a big project that just looks like a second system. Basically is the rewrite of a BIG As/400 application to a .net frontend -> java backend through web service.
At the moment I can’t tell how is it going to end but it is an awful lot of work… :-(
Franck said,
Oct 25, 2007 at 1:17 pm
This is an interesting version of the “good enough” theory that tries to teach us where to stop in an effort to switch to other priorities.
P.S: You should check how you associate “time” with your posts, because it seems that you are already October 22… and on my calendar it is only October 3 ;o)
Anonymous Coward said,
Oct 4, 2007 at 12:40 am
I’ve created a kick-ass system at work, that is getting attention from other parts of the company too. Why am I rewriting it from scratch? Because I’m too ashamed of the code produced by short deadlines and huge work load.
Mike Kaufman said,
Oct 4, 2007 at 12:50 am
Brooks also says “plan to throw one away; you will, anyhow”. Which clearly implies a “second system”.
I don’t think Brooks is saying that a “second system” is inevitably a mistake (as he points out, an architect can’t just skip his second system). Nor is he necessarily just referring to a rewrite or other such second attempt at the same system. Much of the chapter talks more generally about an architect’s second “task”.
Instead, I think he’s just pointing out that what an architect thinks they have learnt from their first system can make them overly bold and can generally lead them astray when approaching their second system. In particular, they then have exactly one example to draw lessons from, and can’t tell what’s specific to that one example and what has a broader truth. We need to be aware of this and take it into account, both in terms of self-discipline and in how we manage projects (e.g. not regarding architects as fully competent until after they’ve worked on multiple systems – though nowadays I suspect the tendency is to regard people as senior achitects even before their first system).
In any case, however much I enjoy and admire Brooks’ book in its context, we shouldn’t blindly take all of it as an absolute gospel truch regardless of circumstances. For example, in those days the technology and requirements didn’t “churn” as quickly and there was a lot more similarity from one project to the next than I ever see today (though maybe that’s just me…). Some of the economic trade-offs might also be rather different now due to different tools and techniques (for example, the “extreme programming” movement is at least partly based on an explicit recognition of how modern approaches have changed these trade-offs).
To quote something else from the same period, and in keeping with your 42!,42!! post, the key is to always “Think”.
Miro said,
Oct 4, 2007 at 5:04 am
You have pointed out several valid concerns – but what do you suggest as a solution ? Do you see any way “out of the trap” ?
Cerberis.EU Blog » Blog Archive » Second System said,
Oct 4, 2007 at 4:46 pm
[...] Second System Oct03 3 October 2007, admin @ 4:07 pm From: The Second System [...]
James said,
Oct 5, 2007 at 2:28 am
I haven’t read the book. Very interesting idea. I’ve been working on a second system for years. My main objective is to make it so that someone besides me can figure out how to configure it. I just spent 11 hours yesterday making the major changes to core that are needed to make it understandable but in the process broke all functionality. I’ve been putting yesterday off for months because it sucked so bad and now I got to go line by line and fix everything. Maybe I should have just stuck to the first system. Well, it was already the second system. Yesterday began the third system. Anyway, I’m just hurting my job security, right?
Mehrdad said,
Oct 5, 2007 at 5:25 am
My two cents:
“Second system” is the way of nature! Biologists call it “Evolution”. You change and update to adapt. In evolution, the result and the functionality counts, the design is the second issue. You go for the “Second system” because the very “cool features” can keep you on the top. If you don’t, others will and your tool becomes irrelevant, i.e. you go extinct!
So may be sticking to the “first system” is the real trap that prevents you from progress!
David Durand said,
Oct 5, 2007 at 8:02 pm
One thing missing from this post is that Brooks counts higher than two. The first system succeeds because fear of failure forces pragmatism in building. The second system fails (or is a bloat-master) because it’s over-generalized dues to ambition and confidence. The Third systems (and after) are the best. They’re better built than the cramped first version, but ambition is tempered by the experience gained from the runaway second version.
While this is a learning process for all software architects and engineers, even experienced engineers may fall back into the trap if they move into a different enough area that they lose perspective.
Ramachandran M said,
Oct 6, 2007 at 9:51 am
Grate expression born out of deep impression.
I am also involved in the development of a second system in one way or other so I can appreciate your view point. What about this point of view. Software developer is rather considered as creator who enjoys his creation than an employee who do some mediocre work.. Especially when he is an architect . Every creation is painful and is born out of no mind, which will be normally simple and intelligent. It is actually an intellectual property of the person. The term Intellectual Property (IP) reflects the idea that its subject matter is the product of the intellect. The very reward of creation is the joy we get out of it. If it is frustrating then it is born out of mind. In this point of view is it not better to be caught in a trap…?