Evolving Software Politics

I find a lot of insight in Steve Yegge’s suggestion that we think about the world views of software engineers along a conservative (risk-averse) versus liberal (change-friendly) axis. I have some quibbles, to be sure:

  • I’m not sure how well Steve’s labels resonate outside the U.S.
  • I think software conservatism is more focused on permanence than risk aversion.
  • I don’t think programmers are all that consistent in their views. I can find evidence of both soft-con and soft-lib thinking in my own philosophies.

That said, I think I’ve evolved from a conservative to a more liberal perspective over the years. At one point in my career I got quite annoyed at C++ coders who were careless about how they used const. It still bothers me a bit–but now I care about productivity more, and I buy the value of languages enforcing best practices less, than I used to. I love python and “convention over configuration“–both liberal favorites. My idea that teams should deploy evolving software by assigning humans to role play architectural components, and see what happens–that’s about as ultra liberal as it gets.


Why has my world view evolved?

I think I’ve come to agree very strongly with Steve’s observation that software is impermanent. Little if any software stands the test of time. In the mid ’90s I worked on some Visual Basic code that had ancient Basic modules in it, with comments from the mid 70’s. I hated that code–imagine the worst features of spaghetti code, hungarian notation with obsolete data types, deep technical debt, tight coupling, poor encapsulation…–this was a poster child. The code wasn’t dead, but it should have been. 20 years is too long for almost all code. (I’m adding a chapter about the profound benefits of death in my biology~software metaphor, in my forthcoming book, Lifeware.)

When you accept that software is impermanent, you can relax. There doesn’t have to be a centrally planned vision that remains constant over time; you can discover things as you go, and it’s all right.

Don’t confuse this with me being lazy. I think code should be clean and cohesive; see my posts on “good code” for more on that. I’m simply saying that you should embrace the idea that things change. Requirements shift. Teams go through learning curves. Staff has turnover. Products lose or gain competitive advantage. The market adjusts. Better frameworks come out. New OS features appear. And the implication of this change is that today’s right answer might need some tweaking tomorrow.

Faced with that change, the ability to react quickly and calmly, to be entrepreneurial and experiment-driven, is often of greater business value than a perfect piece of code.

Action Item

List three things about your project’s landscape (market, team, technology, …) that have changed in the past year. Do any of these make earlier decisions more or less appropriate?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s