I signed two software manifestos yesterday.

photo credit: SpecialKRB (Flickr)

The Agile Manifesto is a classic. It changed the industry. Not everything about “agile” is automatically wonderful (particularly when it becomes an excuse for lazy planning), but the foundational principles are so, so true! Go. Read. Sign.

The Manifesto for Software Craftsmanship seems to deliberately emulate its predecessor’s simple and pragmatic style. I also believe deeply in its principles. I think it needs a bit more defense, however.

Steve Yegge claims that software conservatives love their code, and software liberals view code as a necessary evil. (LONG post; this comment is near the end. And you may need to read his previous post for context, if you’re not familiar with his political metaphor.)

I think he’s gone too far. I’m pretty software liberal. And I get the kernel of truth in the “necessary evil” idea. So much of what we write will be chucked or rewritten; it’s unhealthy to imagine that every project is an opportunity for a magnum opus, or to expect to be able to achieve perfection.

But I don’t think that means we should devalue the craft. Even in the imperfect, muddled, transitory universe of software, it’s possible to make savvy and artistic choices–or to do the opposite. When we care about craft, we find work more satisfying, and we make our corner of the universe a more hospitable place for our neighbors, which has all kinds of benefits.

Besides, love of craft is my major reason for blogging, so it must be a good thing, right? :-)

Action Item

Go read the manifestos. If you’re inclined, poke around for the links that let you sign.

Role Models

This is the inaugural post in a series that highlights people who’ve influenced me.

Almost everything useful that I’ve learned about software comes from observing great practitioners of the craft. It’s my good fortune to know many.

Sometimes I’ve learned from overt teaching–lunchtime training sessions, discussions around whiteboards, talks at conferences, emails and blog posts…

“… When necessary, use words.” Image credit: Jusepe de Ribera (Wikimedia Commons)

More often, however, the deep lessons soak in over time, as I see a colleague model alignment to a value that they’ve internalized. Supposedly St. Francis of Assisi said, “Preach the gospel at all times. When necessary, use words.” Put that in a business context; who have you known that’s preached an eloquent sermon to you about the art or science of software by the way they decide, talk, or behave?

Over the next little while, I’m going to post about some of these role models, and the lessons I take from their examples.

I apologize in advance for a few things.

First, any list of mentors that I offer is going to be woefully incomplete. In three minutes of brainstorming, I already had a score of people/principles I wanted to talk about; I’ll never cover everything that deserves mention. Even when I cover something, I may not be able to highlight everybody who’s taught me a given principle.

Second, my memory is imperfect. I may remember something in a way that’s different from a mentor’s recollection–either because I experienced it differently in the first place, or because I’m starting to have senior moments. Inaccuracies are inadvertent and will be gladly corrected, if anybody can set me straight.

Action Item

Make your own list of mentors. I’ll bet you’ll be surprised at how long it gets.

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?

Are You Designing an Apex Predator?

(This post is an excerpt from my forthcoming book, Lifeware. Follow my blog [see right sidebar] to catch the publication announcement.)

A paleontologist walks along a canyon. She finds part of a fossilized crocodilian skull in a layer of sandstone. She immediately knows that this creature’s environment was wet and warm, with an abundance of animal and plant life at all layers in the energy pyramid. In fact, that single clue implies an entire ecosystem with an amazing amount of detail.

Crocodylus Porosus: eats competitors for lunch. Photo credit: Molly Ebersold (Wikimedia Commons)

Her predictions derive from the fact that adult crocodiles are apex predators. They’re at the top of a food chain which stretches down through medium-sized herbivores, omnivores, or carnivores (in modern times, a zebra or jackal, for example), to smaller omnivores and herbivores (fish, turtles), to insects and nematodes and molluscs and arachnids, to plants in a thousand varieties… At every trophic level in the energy pyramid, there’s roughly 10x the biomass of the layer above it, so one crocodile implies a lot of bugs and reeds and mangroves.

Ask a kid for his favorite animal, and you’re likely to hear about an apex predator: tiger, orca, polar bear, great white shark, eagle. The freedom, fearlessness, and power of these animals captures our imagination.

Kids who grow into software engineers have an affinity for complex software “organisms” with highly developed competitive advantage. They still love apex predators.

As my friend Chris was pointing out to me yesterday, a highly evolved design comes naturally in software. Structural engineers are constrained by gravity and tensile properties of steel to not attempt bridges across the ocean; software, on the other hand, has much fuzzier (and more poorly understood) limits.

But here’s an important lesson from biology: apex predators require a rich, layered ecosystem in which their adaptations can shine. Take a crocodile and plop it down in the middle of the Sahara or the artic tundra; how long will it survive?

Software is the same way. If you are designing an enterprise application that offers rich reporting, seamless transitions to and from the cloud, sophisticated licensing, integration with management frameworks and directory services, single sign-on, and industrial-strength security, you are designing an apex predator. That’s cool. But is there enough “biomass” in the environment to sustain your killer app? The enabling environment has to include trained support and sales staff, analysts, VARs, professional IT organizations with time and budget, a friendly legal climate, whitepapers, a developer community, and so on and so on. If you don’t have this, your apex predator will die. Make sure you understand the ecosystem implied by your design; addressing the environment is as much a part of the design and development as the UML diagrams and the WSDL.

Cheating is possible. You can keep crocodiles alive in a zoo without an acre of mangrove swamp, and you can short-circuit VARs and skimp on whitepapers and so forth. But cheating is expensive and suboptimal. And even cheating requires plenty of planning and investment.

An alternative to cheating is to not try to build your apex predator until the ecosystem evolves. Maybe you should settle for a handful of snapping turtles and a snake, until the swamp’s big enough to house a crocodile. Snapping turtles might not be a bad business… This choice isn’t the same as abandoning a vision–it’s just realizing that ignoring the timetable of evolution may be unwise.

Action Item

Look at your roadmap. Is the next round of releases going to drop an “apex predator” on the market like a crocodile in the arctic? What must be true of the ecosystem for the product to succeed, and how can you make those things true?

Users Aren’t The Only People In Your Software

I’m all for a healthy focus on HCI (Human-Computer Interaction), UCD (User-Centered Design), and UX (User eXperience). (See my post about role-play centered design, for example.)

However, some insight gets lost when we think that only “end users” interact with our software, and only their experience needs to be polished.

With enterprise software, it’s common for lots of people in the customer’s value chain to interact with the software to one degree or another. Perhaps IT specialists use the software every day, but need to provide upper management with periodic reports or dashboards. If so, those touchpoints with upper management are also a form of human-computer interaction, and also deserve attention. What about the CIO who is deeply aware of C-level pressures to reduce costs in his organization? He has to somehow justify each line item in his budget. The enterprise software that gives him a convenient, compelling cost savings report is making a savvy UX move. How about the evaluators that see the product before a purchase decision is made? Does their experience matter?

It’s not just the consumer side of the value chain that’s studded with interesting people. On the producer side, dev and test engineers interact with the software all the time. Although their convenience is not the highest consideration, an utter disregard for their use cases can sap team morale and productivity. Less obviously, but perhaps more importantly, you have interactions between the software and your support team, your marketing team, the executives that sponsor the dev budget for the product, and so forth. If you’re doing SaaS, you’ve got infrastructure/datacenter staff. If you’re building an app, you may have content creators or maintainers. All of these people matter.


Action Item

List 3 people besides end users that interact with your software in important ways. How well does your software communicate with them and satisfy their need to be productive and drive business value?