Interesting software vs Plumbing

What makes interesting software? What makes hard software? What makes fun software?

Customer affinity

It all started with Martin Fowler post: CustomerAffinity. In this blog entry, Martin makes the point that "enterprise software" can be much more than "boring" and "shuffling data around". If you have enough interest for your customer (CustomerLove?), you can be pretty much delighted by finding the best ways to solve his business challenges.

So, as a programmer, even if you should be interested in frameworks (he calls that "plumbing"), you should be even more interested in the business that's supported.

Well, this has been more or less my opinion for years. I love to formalize, structure the fuzzy concepts that business people are toying with.

It is fascinating to see how human creativity can elaborate very complex things from very simple ideas. For instance, Thales is seemingly credited with the idea of buying the option to use olive presses during the next harvest. He bought the right to use something from sometime in the future. Now, play with the words in italics and you will get all the subtle ways to define options.

Is it boring?

Fine, fine, but Ravi Mohan disagrees with force (But Martin, entreprise software IS boring). He advocates that the talentest programmers would rather code a compiler than a loan-disbursing process.

So, "Computer science" and mathematics could be much more interesting than "enterprise software"? Reginald Braithwaite entry about business programming provides some answers.

Not only, getting the concepts right can be interesting (how do you define a "fraud suspicion"?), but this can raise really interesting computing issues. He takes the example of a system for routing concrete trucks: what are the optimal paths if you take the traffic into consideration? What if an accident occurs?

And Reginald raises the bar higher: can you do it in real-time? For thousands of trucks?

So, what's interesting in software? We can get some hints from those blogs:

• customer business (Martin's interest)
  
• mathematical / algorithmic challenges (from Reginald's blog)
  
• scalability / performance issues (Reginald again)
• computer-related stuff : languages, compilers, protocols, graphics-intensive software,... (Ravi )

I would also add one source of interest that is rarely given much interest as such: maintainance. Bleech! bad word, how can it be desirable? Well, when you code and design software day after day, you can also meet pretty tough challenges around maintainance. Is your code readable enough? How is conveyed your design? Can the software be plugged, unplugged gracefully? All these questions sometimes require specific talents that may be not found in the "hardcore programers" set. So, let's add one more point to the list of what makes software interesting:

• software maintainance 'art'

Fun happens

So far, so good. There's even a good news: you may have to deal with all of these in your next software project! The chances are very thin but software is such a continuity that you may have to implement a software for hospital management:

• what's the content and life of a medical file?
• how do you allocate efficiently resources such as rooms, surgery equipment? (what if a big -think 'terrorist'- accident occurs?)
• how do you do that for thousands of patients, in real time?
• how do you get x-rays pictures from the equipement to a secured medical file?
• how do you support a domain-specific language for an expert database?

Anyway, you will be bored somehow

Fun stuff, no doubt. So, what's REALLY boring? I'll tell you. This is what -I- call "plumbing":

• software compatibility: "oh, version X.Y.Z is needed for this dll!"
• environment variables: "BLOB_DIR was not set. How was I supposed to know that?!"
• defining paths, installing stuff: "a new Windows update is there, you should restart your computer"
  
• interoperability: "this very useful piece of java code is supposed to communicate with this VB crap,..."
• fighting with your programming language to express simple ideas: "look! 6 lines of java vs 1 ruby line of code"
• lousy operating systems: "what?! cmd.exe can not display ansi codes? What year are we?"
• fiddling with your UI framework to get what you want: "why on earth is this not resized?"
  
• and yes: business software that's repeating itself, either in the concepts or in the implementation,...
  

In the end, I feel it is very important to track the "boring" parts of software. Either make them disappear or become very good at dealing with them efficiently or hire someone to do that for you (why would "boring" be an universal definition?)!

And,... allow yourself to play from time to time.

So relax and enjoy

This is why I appreciate the RubyQuiz. This week's quiz is about a compression algorithm. I had a chance to learn a completly new field for me, without pressure nor any of the 'boring' constraints. I had everything at hand with a ruby interpreter (ok, not entirely true: I installed Radrails,...).

Another grid of evaluation for recruitement

Concluding thought. All those points can be considered when hiring someone:

• comfortable with concepts?
• has knowledge of the mathematics, algorithmics involved in programming?
• knows how to deal with scalability/performance issues (both in software and hardware?)
• is confident with parsing, ASTs, GUI, disk accesses?
• can produce maintainable code?
• can minimize the effects of boring activities? (knows how to install a full production system without spending hours on the web?)

Wow, this looks like a whole program that I can apply to myself! And I didn't even talked about project management and people,...