Software Construction is Broken

From 2004 Guide to the IEEE Software Engineering Body of Knowledge:

1.3. Constructing for Verification [Ben00; Hun00; Ker99; Mag93; McC04] /></a></b></p> <p align=

Anticipating change is supported by many specific techniques summarized in topic 3.3 Coding.

Many other citations on the page show similar escaped (pun intended) HTML. Is it intentionally ironic that the SWEBOK site itself is broken?

 

n00b vs. veteran developer

Stevey “Long Long” Yegge strikes again.

And this time it cuts twice: first it wasted a lot of my time as usual, then it showed why I suck at being a developer: I can’t get over the n00b mentality and capacity.

OK it’s not that bad. I’ll never be able to write a compiler or understand LISP, but I don’t think my code has that much of a chance to be honored on the Daily WTF, either.

This is the paragraph that makes me sweat (bold by me):

A programmer with a high tolerance for compression is actually hindered by a screenful of storytelling (referring to long comments). Why? Because in order to understand a code base you need to be able to pack as much of it as possible into your head. If it’s a complicated algorithm, a veteran programmer wants to see the whole thing on the screen, which means reducing the number of blank lines and inline comments – especially comments that simply reiterate what the code is doing. This is exactly the opposite of what a n00b programmer wants. n00bs want to focus on one statement or expression at a time, moving all the code around it out of view so they can concentrate, fer cryin’ out loud.

I would always cringe at the LISP code segment he quoted, not just because it’s LISP, but mostly because it’s too terse and dense, exactly as he wants it. My current team lead writes code just like that, and now I can understand his smirk whenever I ask him for more comments.

Stevey’s take home messages are clear, balanced, and easy to follow, though. The essence is the same as the original Agile Manifesto, which is working code (including test code) is the one and only true goal of development. Not any kind of artifact (Stevey calls it metadata) like process, model, and documentation.

When in doubt, don’t model it. Just get the code written, make forward progress. Don’t let yourself get bogged down with the details of modeling a helper class that you’re creating for documentation purposes.

If it’s a public-facing API, take a lesson from doc-comments (which should be present even in seasoned code), and do model it. Just don’t go overboard with it. Your users don’t want to see page after page of diagrams just to make a call to your service.

Lastly, if you’re revisiting your code down the road and you find a spot that’s always confusing you, or isn’t performing well, consider adding some extra static types to clarify it (for you and for your compiler). Just keep in mind that it’s a trade-off: you’re introducing clarifying metadata at the cost of maintenance, upkeep, flexibility, testability and extensibility. Don’t go too wild with it.

 

Security by Obscurity

No I’m not talking about IT security.

I’m talking about job security by information obscurity. It exists in any profession, but is particularly onerous in software business. If you write obscure code with no comment or documentation that “just works” (if it doesn’t even work, it’s called stupidity), and no one else in the world could maintain the code but yourself, you’re a master of SbO.

And even sometimes you can’t understand your own stuff. So you happily reinvent another wheel, and proclaim the extra honor of Security by Confusion from Multiplicity.

For a software company, SbO is one of the most dangerous things. Not able to fire you is the last of the company’s concerns. Sure you’ll demand hordes of guaranteed bonus and exponential raise, but the CFO should be good at playing financial tricks.

The problem is that productivity is hurt on a daily basis. Other developers can’t possibly make any sense out of your code unless they timidly ask you. And an M.S.bO is usually a Master of Incomprehensible Speech. You talk too fast, or too slow, or too loud, or too low, or monotonic like a metronome, or hysteric like a hyena. And usually with a heavy Indian or Russian or Chinese or Brooklyn or whatever accent.

And if probability forbids, an accident wipes you off the face of the earth, which leaves the world a better place to be in general, but the company in a terrible state of panic.

On a philosophical level, I think it relates to different strata of freedom. The lowest level is what almost everybody is stuck with: do whatever you want. So you think you’re free to obscure information.

However, you cannot hinder other’s freedom by your act of freedom. If half of the people realize this, Communism is realized. Other developer is free to get information on your code for whatever reason: they need to maintain it, use it, or simply study it for recreation. So you can NOT obscure information to hinder their freedom.

On the highest level, you sacrifice your own freedom to boost other’s freedom. If half of the people just think about doing this once in a while, we have heaven on earth. So you write plenty of comments and documentation, keep them up-to-date, write wiki and blog, call a tutorial session on your new library, open source it with BSD license.

I would then renounce my atheism and worship you wholeheartedly, my God of Code Freedom.

 

Agile and Google

Joel On Software linked to this long post bashing Agile, using Google as example. This Stevey Yegge guy used to work at Amazon and likes to write LONG blogs.

I don’t agree with all his points, but I understand his disdain for those “methodologists” who make money from books and seminars and consulting gigs on “process improvement”. Alas, I wasted a couple years of my own life in that.

Also I don’t think it’s appropriate to use Google as a universal example. Google is different in too many aspects from most software shops, most importantly its business model and its development methodology (or the lack therefore) derived from it. Most software projects don’t have the luxury of NOT defining a release date. Whether most software shops should try to imitate the Google Way is another topic, but I doubt that’s the case because that would make the Google Way just another (anti)methodology that doesn’t work universally.

But I do love so dearly about many points he made. And it’s cliche but Google does look like a programmer/engineer’s dream job: work hard AND smart, work with great people, work on interesting AND hard things, be rewarded in all noble/abstract and mundane/practical ways, and of course most of all, your work matters to the world and makes it a better place.

Some striking things about the Google Way (stuff in italic is from 8/28 issue of Information Week):

• Managers = tech leads, they code at least half time
• Developer can switch team/project at any time for any/no reason (every 3 months)
• Developer SHOULD spend 20% work time NOT on her main project
• Meetings are rare, and only occur during midday, so that developers don’t get interrupted when they’re in the zone (usually very early and late).
• Performance review is all public
• Custom made for efficiency: server hardware, web server, MapReduce, BigTable, Sawzall (intepreted language), GFS, etc.

Some quotes:

Google can be considered a fusion of the startup and grad-school mentalities: on the one hand, it’s a hurry-up, let’s get something out now, do the simplest thing that could work and we’ll grow it later startup-style approach. On the other, it’s relatively relaxed and low-key; we have hard problems to solve that nobody else has ever solved, but it’s a marathon not a sprint, and focusing requires deep concentration, not frenzied meetings.

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I’ve even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places.

We do have project managers and product managers and people managers and tech leads and so on. But the amount of energy they need to add to the system is far less than what’s typically needed in our industry. It’s more of an occasional nudge than a full-fledged continuous push. Once in a while, a team needs a bigger nudge, and senior management needs to come in and do the nudging, just like anywhere else. But there’s no pushing.

---

UPDATE: Stevey has a follow-up. It’s also super long but super hilarious, an animal farm with The Carnival of the Animals soundtrack: cat, dog, chicken, pony…

One thing he’s not clear about, though, is the testability of any methodology. Well nothing is truly testable, according to Heisenburg. It is particularly true for anything that deals with human and has time lapse, like software development, or society at large. It’s simply and categorically impossible to have a double-blind test of two methodologies because you cannot guarantee an identical environment for both.

Anyway, I think two points should be well taken in any case, for software development, or life in general:

• Be suspicious. Have some doubt. Don’t take anything too religious, especially yourself and what you think is right.
• Be humorous. Have some fun. Don’t take anything too seriously, especially yourself and what you think is right.

 

Requirements Wisdom

From SD Magazine 2005/10.

Collaborative requirement elicitation:

• Active Stakeholder Participation: an Agile Modelling method
• On-Site Customer
• Focus Groups
• Face-to-Face Interviews

Traditional (restricted interaction):

• Joint Application Design (JAD)
• Observation
• Electronic Interviews
• Legacy Code Analysis
• Reading