The Appreciation of Software – we are nowhere


I have been listening and waiting patiently, while watching one of the many shows on the History Channel, the Discovery Channel and the Egyptian Antiquities Channel (OK, fine, I made that last one up…) for one of the pyramid experts to sit back smugly in his overstuffed chair and say, “They’re just a pile of stones, how hard could that be???” Needless to say, that never happens. Instead, they go one for hours, puzzled and amazed, giddy about the engineering and construction feats of these ancient Nile Valley dwellers.

Granted, I am amazed as well. But why can’t just a smidgen of that appreciation spill over into our software universe? What are we doing wrong??

I was with a client for two straight days this week, acting (and I stress acting) as the subject matter expert for an enterprise Project Management Office and Decision Support System for the government of an emerging third world country. For a day and a half I patiently gathered requirements, sketched out architectural alternatives and tradeoffs, and modeled data flows.

Toward the end of day 2, I had the audacity to imply that to electronically and ‘automatically’ provision new projects in the EPM tool of choice from a legacy budget authorization system might be technically challenging (not impossible) and could involve things like workflow and transaction management. I stated my case in layman’s terms.I was brilliantly articulate. Not condescending at all, just enlightening.

I paused at the end of my explanation, sat back, and waited for the nods of understanding. “Ah, that was wise, Bob. Thank you. We didn’t really appreciate the complexities of trying to do this in Phase I.”

That’s what I expected to hear. But you already know what happened, don’t you? Their body language said, “How hard could that be??” Their words said, “We really need it to do that.” Their faces showed disappointment. I, of course, relented (who wants to disappoint a client?) and said, “I am sure we can figure out a way to make it do that…”

We are nowhere.

Gone are the days when hulking mainframes lurked in a data center behind security doors, air-conditioned to a temperature you could keep Dove Bars in, when the general public had a fair amount of awe and respect for the “programmers” who made these machines do their bidding. Since then, end user expectations have gone up. Appreciation for the inherent complexity of software has gone down. And with that, quite a bit of whatever mojo we ever had.

I am in complete awe of what you can do with an iPhone and the remarkable engineering feats that must have made that possible. Am I the only one?

With the same determined spirit that keeps us going when there are more bugs this week than last week, let’s vow to take the time to educate and enlighten one end user. No matter how long it takes and how persistent we have to be, let’s find a way to help them see that software engineering is still challenging and its practitioners still worthy of some level of admiration. Even if we’re not piling stones on top of each other…

Explore posts in the same categories: Client Management, Expectation Setting, Scheduling, Software Development

Tags: , , , , ,

You can comment below, or link to this permanent URL from your own site.

3 Comments on “The Appreciation of Software – we are nowhere”

  1. ilya Says:

    Come on now – you’re calling iPhone impressive? it’s at least 0.25″ thick. i mean, all those atoms and electrons are waaaay smaller than that. how hard can it be to stuff them into a gigantic case the size of an iPhone?

    Let’s face it… the mumbo-jumbo that goes on behind the scenes in software development is a far cry from the sheer physical scale of masonic undertakings. More importantly, perhaps, the simplicity of explaning the project’s details differs greatly between “move big rock from here to here” and “move these almost imaginary bits from here to here”. One is clearly ridiculously hard with or without diesel-powered machinery, and the other one begs the question “how hard can it be?”. From that perspective, i think the software development profession is going to lose out, in terms of screen time, on the Egyptian Antiquities Channel (i love that channel, btw).

    additionally, we need to seriously rethink the real value of Open Source and its place anywhere (except for research and academic environments). i think the Open Source movement, subsidized by hardware manufactorers who gain the most from minimized cost of stuff that makes their equipment useful, has done quite a lot to damage the perception of the value of intellectual property in software development.

    i don’t think mere education will change the situation.; people will still think “this guy’s trying to rip us off… he’ll spend 3 weeks playing online poker, and then build this thing for us in a week, ’cause – how hard can it be?”. I think demonstration of underlying complexity must be tangible, visible, and reflect the effort that went into making that complexity disappear behind shiny buttons.

    And i also think we should start wearing white lab coats to work.

    • mgtstr8talk Says:

      Excellent feedback. I like the lab coats idea. It works for the medical profession! And I agree that, all kidding aside, the demonstration of underlying complexity DOES have to be tangible and visible. Any thoughts on how to accomplish that when source code is so amazingly obfuscated and electrons are so small?

  2. ilyal Says:

    1. on the application front-end, complexity ought to be hidden from end-users. having said that, though, i fully subscribe to the idea that the UI should remind the users of all the good things it’s done for them – “this widget has saved you NNN hours of mindless typing to-date”, or “helping you do less work since April 2009” or something like that. These data can come directly from the application’s usage, if applicable, or from the business case for developing the application. Obviously, each app will be different, and for middleware may come as a monthly report for those who paid for it, for example.

    2. the stake holders of a project ought to be exposed to complexity as much as possible and as frequently as possible. Agile approach to development would be helpful there, as it encourages frequent interaction with the customer. However, i’m not sure if Agile methods apply to a pre-sales cycle.

    By the way, is it possible that the emerging country’s representatives’ “how hard can it be?” stance is a negotiating tactic? It’s almost logical that they’d follow it up with “well, we’ll just go talk to someone who’s figured this stuff out and it’s not sooo hard for them”. 😉


Leave a reply to ilya Cancel reply