Guest Opinion

Software Is Too Darn Hard

Rockford Lhotka argues that the software development process is overly complicated, with an emphasis on what is fun for the developer to do, but with too little consideration of the user's needs.

• By Rockford Lhotka
• 04/01/2006

Software development is too darn hard. As an industry, we spend more time discussing "plumbing" issues like Java versus .NET, or .NET remoting versus Web services, than we do discussing the design of the actual business functionality itself.

Even when we get to the business functionality, we spend most of our time fighting with the object-oriented design tools, the form-designer tools that "help" create the UI, the holes in databinding, the data-access code (transactions, concurrency, field/column mapping), and the database design tools.

Users neither care about these issues, nor benefit from them. Oh sure, we convince ourselves that they do, or that they'd "care if they knew." But they don't.

Users want a system that does something useful. An underlying problem is that building business software to solve users' problems is ultimately boring. Most of us get into computers to express our creative side, not to assemble components into working applications. If we wanted to do widget assembly, there are many other jobs that would provide more visceral satisfaction. Carpentry, plumbing, and cabinet making all provide the ability to assemble components to build nice things. These jobs have a level of creativity, too. But they don't offer the level of creativity and expression you get by building your own client/server, n-tier, SOA framework. Using databinding isn't nearly as creative or fun as building a replacement for databinding.

And this is the root of the issue. The computer industry is populated largely by people who want to build low-level stuff, not solve high-level business issues. Even if you go with conventional wisdom—that Mort (the business-focused developer) outnumbers Elvis/Einstein (the framework-builder) five to one—there are still enough Elvis/Einstein types in every organization to muck things up for the Morts.

Consider this: I dusted off VB3 a couple years ago and gave it a test run. VB3 programs are fast—blindingly fast! It makes sense; they were designed for the hardware of 1993. More importantly, a data-entry screen built in VB3 is every bit as functional to the user as a data-entry screen built with today's trendy technologies.

The primary fault lies with us, as software designers and developers, but there's no doubt that the vendors feed into this as well.

We've had remote-procedure-call technology for a long time. But the vendors keep refining it every few years: They've got to keep the hype going. Web services are merely the latest incarnation of a long sequence of technologies that allow you to call a procedure/component/method/service on another computer. But Web services don't make the user more efficient than DCOM. Nor do they save the user time or keystrokes.

We justify these things by saying they will save us time. They'll make us more efficient. My guess is that users don't have a clue that the technology landscape has changed out from under them over the past five years. They see the same software, with the same mismatch against the business needs, and the same inefficient data-entry mechanisms they've seen for at least the past 15 years.

No wonder they offshore the work. We (at least in the U.S. and Europe) have had a long time to prove that we can do better work, that all this investment in tools and platforms will make our users' lives better. Most of what we've done hasn't lived up to that hype, however, so it shouldn't surprise us that our users feel they can get the same crappy software at a tiny fraction of the price by offshoring.

My friend Kathleen Dollard made the comment recently that all of Visual Basic (and .NET in general) should be geared toward Mort. I think she's right. Visual Basic and .NET should be geared toward making sure that the business developer is exceedingly productive and able to provide tremendous business value to their organizations, with minimal time and effort.

If our tools did what they were supposed to do, the Elvis/Einstein types could back off and just let the majority of developers use the tools, without wasting all that time building new frameworks. If our tools did what they were supposed to do, the Mort types would be so productive there'd be no value in offshoring. Expressing business requirements in software would be more efficiently done by people who work in the business, who understand the business, language, and culture, and who have tools that allow them to build that software rapidly, cheaply and in a way that meets the business need.

[Note: This guest opinion was adapted from a weblog at www.lhotka.net/WeBlog.]