The 7 Rules of Software Development


Nuremberg_chronicles_f_180v_1I hate simplistic blogs like “The 10 Rules of XYZ”, but who am I to buck the trend?  Why the picture?  Every time I read one of these simple lists of edicts it strikes as being very “papal”.  Here I’ve simmered down development into 7 rules:

1. There is No Such Thing as Architecture, and you should avoid “Architects”

Good software developers work in small teams, they discuss everything, and the really good ones understand that “architecture” doesn’t really mean much.  Yes there are choices about what software “stack” you are going to use and how components of the system interact, but it is a fools errand to view “architecture” as something separate from development.  Software is built up piece-by-piece, and you make a thousand little decisions here and there, all of which end up in a final structure.  Developers can discuss “an architecture”, but it is just an abstraction, it doesn’t really “exist” outside of the system as it has been implemented, and it is more ceremony than anything else.

The problem with the whole idea is that it suggests an analogy to construction, you know “real” architecture. We’re not in the business of standing up houses and/or buildings, but, invariably, every time someone tries to create an architecture they end up drawing models that almost never line up with reality. Let’s retire the word “architect” as it applies to software development I’m not saying that there can’t be a plan, or a loose collection of rules, but it is the really bad developers that get stuck on this idea that there is “an architect” who is telling “developers” what to do.  (That’s the worst kind of place to work.)

That’s not how it works.  You can make it work like this, but, trust me, your software will suck as a result and you won’t be able to grow a committed team.  Why? Because of the next rule…

2. Everybody Grows

Why is there no architect?  A couple reasons. First, every real software architect I’ve come into contact with is a train wreck. They used to be a developer and they were either so incompetent they had to be promoted out development or they were the kind of individual that thought so highly of themselves they fell naturally into the role of dictating design decisions. Second, having someone be “the architect” gives everyone else a good excuse – something to blame when a system falls on its face. When you have an “architect” you’ll usually see disengaged teams, teams that don’t want to stay late because they are excited about the work they are doing, and a corporate culture ruled by political dysfunction.  Think of a room full of disaffected developers saying things like “Well, it wasn’t my decision to do it that way?” and “Well, I don’t know why we did that, go ask the architect.”

The working alternative is that everyone on the team makes a contribution, and everyone on the team is responsible for at least some portion of the architecture (which, remember, is a useless abstraction). The rule is that decisions are made by the people doing the work, and you should rarely override these decisions. This is essential for long-term success. If you force a strict hierarchy on to your development team, you’ll never give anyone the opportunity to grow. What you need is a self-aligning hierarchy (or as close to self-aligning as possible… people still need bosses, don’t get me wrong.)

3. Avoid Developers who think there is an Objective “Right”, There is only “Satisfies Current Requirement”

This is not to say that I believe in a sort of software relativity in which no solution is better than another.  I do believe that there are good ideas and bad ideas, but if anyone on your team decides that they are the arbiter of Right and Wrong you need to have a long conversation about how a team works. You need to remind them that there is no “architect” and that there are really just people responsible for different components of the system. Now, a little disagree is alright, but in my travels throughout developerland I see a lot of developers running around with this idea that they’ve discovered the One True Way. They haven’t, and there isn’t one.

(Note: there’s an exception to this rule: Subject matter experts – real subject matter experts.  For example, if you are in a meeting with someone who, say, wrote a book about Tomcat, and you say something about Tomcat that causes that person to object.  Listen.)

If disputes seem unresolvable, you should absolutely intervene and nudge a decision along.  This is what management is for, but if you have people on your team constantly debating software development dogma, you should stop them.  Yes, there’s a right way to do File I/O.  Yes, there’s a right way to use a UITableViewController in iOS, and, yes, there’s a correct way to configure Tomcat. No, there isn’t one right way to implement an API, there are several hundred, and you have to give team members enough room to screw up.

4. One Metric for Success == The Number of Times you’ve screwed up

If you are writing software worth writing then you are likely doing something that’s never been done before.  (If this isn’t the case, you are likely writing software that shouldn’t be written but that’s a whole different post.)   If you are forging new ground, there’s a good chance that you are going to screw up… frequently. Good software development teams talk about failures in a way that doesn’t ostracize the people responsible. You want a team that can joke about how they made a bad decision.  You want a team that isn’t constantly trying to look invincible to management.  Everybody screws up.

I’m not telling you to reward your worst programmer a special nerf gun because he’s constantly screwing up production, you shouldn’t “celebrate” screwing up, but you should set the tone that mistakes are valuable. Read some Petroski, he’s written good books on engineering failure (if I weren’t such a lazy bastard I’d link to them).   Long story short: if you don’t want to read his books is: failure is engineering progress.

5. “Is it done?” is to be met with Laughter.  There is no “Done” there is only “Satisfies Current Requirement”

I’ve worked on software long enough to realize that there is no “done”. Stop saying that word, it’s crazy. No matter how much you may want to forget about that code you wrote seven years ago, there’s no escaping it. Software is never done, and it will always break. There will always be something left to do.  If your management team is saying things like, “I thought we were done with that?” or “We don’t have to worry about that system it was done years ago?”  It is your job to remind them that software development is an endless pit of risk – an inescapable gravity well of budget allocation.

The two acceptable responses to “Is it done yet?” are “Software is never done” or “Welcome to the Jungle, we’ve got fun and games.”

6. Don’t Believe Anything You Read Online About Development (Avoid Dogmatic Process)

This is the most important rule of all.  Don’t find some easy software development dogma or list of rules and follow them… that includes this blog post. You should be very suspicious of any online manifesto that talks about ideal software development practices or anyone who takes time out of his weekend to write a blog post entitled “The 6 Rules of Software Development”. Please think for yourself.

One of the worst development teams I ever worked on was a team that was heavily influenced by a popular agile consulting firm that will remain nameless. First of all, the software being produced was awful, but I’m not sure that had much to do with the team as much as it had to do with the company that ran the project. There were architects, there was a guy running around telling everyone he knew what was right and wrong, the place adhered to dogma so much so that people quit over it. Including me.

If someone comes to you totally energized about some “Agile manifesto” they just read, or if they start preaching TDD as the One True Way.  Take them aside, let the know that the workplace is no place for religious proselytizing. While there are many good ideas in the software process community there are also many ideas designed to sell books and consulting services.  Every project and every team needs a slightly different process.  There is no cut and dried model for software development because there is endless variation in humanity.

7. When Everything in this Post is a Lie, It’s Time to Move On

Eventually, as the project matures you’ll experience a slow shift to maintenance mode.  “Management” will start focusing on “risk” and asking questions like, “Who is the architect of this system?” or “What is the Total Cost of Ownership for ActiveMQ?”  At this point, every single rule in this list will experience a rapid inversion point.  There will be an architect, there will be strict definitions of senior and junior developers, someone will start telling everyone else they know the One True Way, programmers will be fired for making even slightly wrong design decisions, you’ll start having status meetings that talk about “finishing” the project, and someone will show up with a bunch of cultish books on process and convince management send everyone to an Agile re-education retreat.