The Tired Architect

I fell in love with programming before I knew what it was. I never knew it’d be a way to earn my living. It was fun, and I was young. I programmed without abandon. I wrote tools, games, everything. Because I enjoyed doing it. There is a certain enjoyment in bending the spirit of the computer to your will, through magic incantations.

I never intended to do anything with those programs — other than using them and extending them, obviously. Nobody asked me to write them; nobody paid me to write them. The concept of selling programs was as alien as that of getting paid to eat chocolate. Some programs found their way into BBSes (the internet was not so popular that time..), and others apparently liked it too.

Our story continues: the boy grows up, and gets himself a CS degree. Natural enough, I guess. And then a job. As a software engineer. Fancy name, huh. ‘Neways, he liked it, it allowed him to keep programming. They even gave him his own machine, some programming to do, an air-conditioned office to do it in — oh and yes, salary.

He was blissfully unaware of his trivial role in increasing India’s participation in globalization, or of the socio-economic impacts of outsourcing, or of the ironies of capitalism. He was allowed to program. He loved it.

Technology, apparently, grows faster than your beard. Computers became ubiquitous. Within a few years, people wanted software for every imaginable and unimaginable thing on earth. Software to help develop software. Software to let people play poker. Software to let software play poker. Software for this, that and the other.

And with it came the people — the people who came into the fun world of programming to make profit and salaries. Who would’ve gladly washed cars or mopped floors if that paid a better salary. People who’d sell beer or software, whichever brought them more profit. Managers who talk in terms of estimates, man-hours, cost, schedule and metrics. Business executives who’d to tell you what technology to use. “Software developers” who demand training and documentation — even if the code is available. Who like PHP, and have not heard of Scheme.

Who claim to be the proponents of technology — yet they stand not in awe of this miracle that they’re part of. Who can browse to a website, but not wonder how it is that the bits fly around in a fraction of a second between two machines separated by a few continents. Not wonder about how we’ve created the computer in the image of ourselves, and linked them with neurons and gave them power to talk to each other.

People who see the money in the software business, but not the magical spirit of programming.

I’m a software engineer by profession. I help create, grow and fix software. As demanded by others. Not quite unlike the oldest profession.

I’m a programmer by hobby. I command the spirits that live in the machine. I create magical worlds, enchanting, exciting. My soul pours out through my programs. It defines my emotions, my pains, my triumphs, my life. I’m a Picasso, I’m a Mozart.

What a cruel irony, that you never know what you have, until you have it no more.

That is life. Grok it fast. Before it kills you.

There are four kinds of software engineers that I’ve come across:

• Talented: These are the people who would intuitively guess how something works, and of course, it’d turn out that yes, that’s exactly how it does work. People who come up with a solution so simple and elegant that others feel a bit behind the evolutionary churn. But for some reason or the other, these people are not as productive as one would expect. For various reasons: software is not their primary area of interest, they lack the discipline that engineering demands, or sometimes just plain lazy. You might still want them one your team just for the flashes of insight they provide, if they’re affable enough.
• Skilled: You can spot them by their notebooks. They work hard, they are motivated. They keep themselves up-to-date. They know their job, their goals, and they have the determination to do whatever it takes to get to the goal. They may not come up with an original creative solution, no innovative breakthroughs; and often they know that they would not, too. Skilled people invariably travel far ahead of their talented counterparts. These people you definitely want on your team.
• Talented + Skilled: They go very, very far. A natural flair, honed by hard work and discipline quite often ensures success in all endeavors. You want to be on the team of such a person.
• Talented + Skilled + an opportunity: A lucky break, a hand of God.. Given to a person with talent and skill, the spark turns into a forest fire. These are the names familiar to all people within the organization; names that you’d recognize around the Internet. People whose potential was exploited by an opportunity. A blessing, offered and utilized, by the best recipient. You’d be lucky to know one in person.

So what, you ask? Well, nothing much, to be honest. Just some food for thought.

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.