The Three Systems of Man - How do you build a Third System?

Question

I've been thinking about the story of the Three Systems of Man from the book The UNIX Philosophy. For those of you who aren't familiar, it goes something like this:

• The First System of Man is the one he builds when his back is against the wall. It's klugey, hackish, and doesn't it lend itself to new features.
• The Second System is designed by a team of "experts" who insist they're going to do it the Right Way this time. The resulting system is slow, bloated, late to ship, and over budget.
• The Third System is built by people who have been burned one too many times by the second system. It is robust, scalable, and maintainable.

Obviously the goal in software development is to write The Third System. The author's premise is that you cannot do so without first writing the other two systems. From that we get concepts like "Plan to throw one away" from The Mythical Man-Month. In my limited software engineering career, I've worked on one second system and two first systems that both became The System due to inertia. It feels like there's never enough time or budget to do it right, but always plenty of time and money to do it over.

Has anyone here ever built or maintained a Third System? What steps did you take to get there? Can you really "plan to throw one away" in practice?

Answer 1

I think the key to this is the difference between having the time and money, and experience. If you've built something before, been burned, built it again, got it wrong and then build it again, and you're that rare developer who just knows what works, then you'll get the 'Third System'.

Just having money, time, and a previous failure is not a recipe for success.

Answer 2

The one example of a Third System that I know of is Linux's iptables.

Linux's original packet filtering system was ipfwadm borrowed from the BSDs. After this, ipchains was written, but it turned out to not be extendable in the ways that the community desired.

Thus, the folks who wrote ipchains wrote iptables from scratch. It has survived a long time.

(Technically, iptables and ipchains and ipfwadm are the user-space tools used to manager the kernel packet filter. For Third System, I'm referring to the kernel packet filter as well as the user-space tools.)

Answer 3

This is an interesting question, and it really made me think twice about my original answer to this question. I'm working on what I'd consider a 'Third System', that I designed from the ground up after maintaining and attempting to extend the previous 'Second System'. (I make no claims that my 'Third System' is perfect, I only claim that I spent a whole heap 'o time thinking about what made the previous systems poor, and made great efforts to avoid that). Will future engineers think I've acheived 'Third System'-ness? I sure hope so, but I bet they are going to wonder why I did things a certain way. I think that it's really in the eye of the beholder, whether a system acheives 'Third System'-ness.

I think that having experience is the best step to get to a 'Third System'. As for can you plan to throw one away in practice, yes, you can - by some good ole prototyping. Granted, you can't prototype everything, so maybe that doesn't completely qualify for "throw one away", if you're talking about a version of an entire system, but for subsystems, in my mind, prototyping is a must.

Edit: I think I'm going to pick up The UNIX Philosophy. I wish I had heard of it before :-).

Answer 4

I've built a third system. Not many mind you, but definitely in one case.

I wouldn't say I "threw away" previous ones so much as they launched and sailed with previous projects.

I build CMS systems for my company and every client needs something different. Usually the first product is one built with my back against the wall. Time constraints, budget constraints, technology gold plating...all the standard issues of a bad project with mismatched expectations.

The next iteration is a re-use of the existing code and ideas with a "better attempt" the next time.

In my case, I built a form generation library. It doesn't limit my designers and it certainly doesn't limit my programmers. It just does everything I need it to do with a minimal amount of effort. It's the best work I've ever done but it took several attempts (and several years) at second system attempts, each with a different and usually poorly thought out objective.

With the last result, it just felt right. I knew I had a third system when I realized that the work I had done had transcended the needs of the current project and was able to be applied to every project currently on the horizon easily and adeptly all the while saving my countless hours of actual programming and development.

Hope that helps some.

Answer 5

"Has anyone here ever built or maintained a Third System? What steps did you take to get there? Can you really "plan to throw one away" in practice?"

I've been brought in a few times to cleanup Second Systems gone wrong.

The steps I took are to be frank -- the system built by experts didn't/isn't working. Note that you're calling someone's baby ugly, and you are not liked for doing this.

And yes, we are throwing one way. We're throwing away the ineffective software that's in place. Note that you're saying that the previous software is a cost, not an investment. you are not liked for doing this.

I've been brought in other times to build a working system. Every design goes through all three phases.

1. You don't understand the problem domain (or the technology). The First System is a mixture. It has problem domain kluges and technical kluges. The First System always has both.

   In some projects, management declares victory, puts it into production and users hate it because the problem domain kluges. Developers hate it because of the technical kluges.

2. "Phase II" starts. In a few cases, I have continued on past the initial klugy phase. Now, the real work begins. Fix the problem domain kluges -- dig out the lies the users told, find the business short-cuts and stupid non-solutions. Fix the technical kluges, similarly, requires rework, which requires unittests so that you can refactor.

   Note that the problem domain kluges are the most destructive. Users say "it's just a simple 'copy' of the data" when it's really not a copy but a second reference. Users say "just give me a user-defined field" and then turn that into a magical key that does everything (badly.)

   Throwing away the poorly-defined (or poorly-understood) problem domain stuff is possible. It takes a while for users to wrap their head around what they're really doing. They lobby for "state of the art" process definitions.

3. Eventually, the users realize they mis-defined their business or their relationships or their processes. That's when the Third System can emerge. In one case (so far), I've continued on to this level of problem domain understanding. We're discarding a bunch of problem domain "expert opinion" and arrive at a clear-eyed view of what really happens. It's simpler than the Second System and doesn't have the crap workaround in the First System.

Yes, we threw away two business models. This doesn't appear costly -- it's just analysis and specifications. But -- really -- the old PPT's and plans and what-not are now laughable because they're so out-of-date and myopic.

Yes, we threw away previous software versions. However, we're using a lot of open-source tools, so it isn't very painful to stop using one component and start using another.

Answer 6

Can you really understand or appreciate the 3rd system without ever experiencing the first 2? and is there really a 3rd system (perfection) out there? Some may come close (I can't name any....including the iPod) but maybe that's a good thing, what would a person do once they reached perfection? have a beer?