Abject-Oriented Analysis

The craft of programming is easy to start, but very difficult to master. It’s a long road, littered with the detritus of failed projects, and deep ditches of obsolescence on either side.  On we plod. We all have stories of mediocre talent rising to call the shots while the righteous and deserving are left to scavenge dinner. If only the people who wrote the cheques could understand.

Or, perhaps, it is us who have misunderstood the problem. What if the mediocre programming talent is simply better at solving a different problem? Students leaving school posses very few skills useful in the real world. Yes, they may be able to implement such-and-such data structures, but they seldom know why one structure may be preferable to another.

Part of the problem lies in how the subject is taught. Example are always neat-and-tidy, drawing on problems we all know intuitively. There must be a mountain of books containing class diagrams modelling student-course-teacher relationships. The examples are deliberately contrived, illustrating one structure or technique at a time.

The trouble is, students are left with the impression these kinds of problems are the norm. Once in the workforce, people who were on their way to being rock star programmers flame out and make little impact. It’s not that they can’t keep up with the pace of change, but they can’t make any headway into the business around them. They sulk in their tents whenever their intricate plans are upended by unimaginative superiors or a naive user.

Bad programmers often end up with management eating out of their hand, which I suspect is because they speak the same language. They have no aspirations to write beautiful code, and couldn’t care less. But they are able to make lay people feel they are being listed to, but won’t really improve anything.

Maybe the Real World ought to be part of the curriculum. Requirements for a real project look something like this (assuming the client even bothers to return your calls):

1. The system will facilitate the reporting requirements as described in the Shipping Act of 2001, section 3, chapters i, iv, and vii, with the additional items from section xxi B3 of addendum 2005d.
2. I saw this thing on CSI where they guy could type in someone’s name and get back a list of everywhere he worked. It should do that, but for snow tires.
3. It will build brand value with social media.
4. Fred needs to approve all content, but Alice has to approve what goes into the footer. Bob writes the FAQ and sends it to Mandy, who types it into the CMS. Except when the link to the FAQ is added to the Header, then Fred gets Susan to do it, unless Mandy has a podiatrist appointment, in which case Wendy does it. Susan is often late, so Fred will ask Mr. Soka to find out if Bob has spoken to Amy about it. If Amy can send it to Wendy, Fred will call Mandy and ask her to forward it Gordon and Susan (not that Susan, but the one from accounts receivable).
5. The system must integrate with Wonder Package X, which we bought yesterday. Sorry, no documentation is available.
6. The system will send all user information (name, email address, credit card, birth certificate, etc.) by fax to our branch office in Transnistria, with appropriate spell-checking, delta resolution, and deduplication.

Perhaps we should start with here, and teach aspiring programmers to turn nonsensical and conflicting requirements into problems that can be solved on a computer. Solving clean, well-understood, problems is a useful skill, but an even better one is being able to separate these kind of nice, neat problems from the pile of messy ones in the first place.

Likewise, knowing how to mix a few cocktails does not make one a bartender. Yes, mixing drinks is a necessary skill, but what really matters is keeping an orderly operation, understanding patrons, and giving them a reason apart from alcoholism to keep coming back.