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 )
- software maintainance 'art'
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?
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,...
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?)