‘* one-offs’ Category Archives


What is Programming?

by Tony in * one-offs

What does a programmer do besides talk in programming language? Most programmers would have trouble explaining what they do. Programming is a job filled with details, and keeping track of those details requires focus. Hours drift by and the code appears. You look up and there are all of those statements. If you don’t think carefully, you might think that programming is just typing statements in a programming language. You would be wrong, of course, but you wouldn’t be able to tell by looking around the programming section of the bookstore.

— Ward Cunningham, Foreward, The Pragmatic Programmer


Growing Software

by Tony in * one-offs

Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run. even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit. it should be fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began using this Technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen even if it is only a rectangle. One always has, at every stage in the process, a working system.

I find that teams can grow much more complex entities in four months than they can build.

— Fred Books, No Silver Bullet


The Gap Nobody Knows

by Tony in * one-offs

The gap between promises and results is widespread and clear. The gap nobody knows is the gap between what a company’s leaders want to achieve and the ability of their organization to achieve it.

Everybody talks about change. In recent years, a small industry of changemeisters has preached revolution, reinvention, quantum change, breakthrough thinking, audacious goals, learning organizations, and the like. We’re not necessarily debunking that stuff. But unless you translate big thoughts into concrete steps for action, they’re pointless. Without execution, the breakthrough thinking breaks down, learning adds no value, people don’t meet their stretch goals, and the revolution stops dead in its tracks. What you get is change for the worse, because failure drains the energy from your organization.

Repeated failure destroys it.

— Bossidy and Charan, Execution: The Discipline of Getting Things Done, Chapter 1


Power is Useless with Geeks

by Tony in * one-offs

Traditionally, leadership is conceptualized as a special form of power relationship where leaders have substantial influence over the behaviour of followers and exercise that power for mutual benefit. With geekwork, you are attempting to harness the creativity of individuals and groups in its purest form. And although behaviour plays a role, it is substantially less important than in almost any other form of work.

Because power is about the regulation of behaviour, it has very little effect on creativity. Traditional methods of exercising control have very little positive effect on the inner state of mind of geeks. And so power itself becomes substantially less important a facet of the relationship between leaders and geeks.

We must rethink what it means to lead in the face of geekwork because most conceptions of leadership are intimately tied to notions of power.

— Paul Glen, Leading Geeks, Chapter 1


Boo Hoo

by Tony in * commentary, * one-offs

I was starting to wonder how we had ever believed we were only weeks away from launch. It was a mass delusion. We either hadn’t seen, or had simply closed our eyes to, all the warning signs. Instead of focussing singlemindedly on just getting the website up and running, I had tried to implement an immensely complex and ambitious vision in its entirety. Our online magazine, the rollout of overseas offices, the development of new product lines to sell on our site – these were all things that could have waited until the site was in operation. But I had wanted to build utopia instantly. It had taken eleven Apollo missions to land on the moon; I had wanted to do it all in one.

— Ernst Malmsten, boo hoo

This is a scary book. Malmsten retells the story of how boo spent $135m over 18 months, to achieve total sales of less than $1.5m, and never really seems to understand just how badly they went wrong. He actually seems to believe they achieved something important, or at least interesting. At the point of Boo’s collapse, we’d built BlackStar to a turnover of $1m per month, with a total operating spend (excluding marketing) of less than $2m in the two years we’d been trading. Our product development costs (i.e the website, and all our fulfilment and customer service systems etc) had been less than $200k, whereas Boo had spent $250k solely on the feasibility study for theirs! By the time they were on the verge of collapse, even after significant cuts, Boo still needed $2m per week to survive. BlackStar, with 100 employees, and still growing fast, needed less than $100k per week.

Although Malmsten attempts to take responsibility for many of the shortcomings, it’s mostly in an “it was someone else’s fault, but I should really have sorted it out” way. Other than the quote above, he never really seems to realise that it wasn’t the execution that was flawed – it was the entire approach.

Malmsten even has the gall to finish the book with the final press release on Boo’s bankruptcy which finished: We believe very strongly that in boo.com there is a formula for a successful business and fervently hope that those who are now responsible for dealing with the company will be able to recognize this.

Hopefully the readers of the book will be able to see what Malmsten can’t.


It’ll be alright if I just keep typing

by Tony in * one-offs

This is the same problem people have when writing prose. They think it’s like speaking, where if you say something wrong you can correct it with the next thing out of your mouth – well, not correct it really, but improve it, that is, when you didn’t say it perfectly in the first place and then you have a new idea – it’s sort of like oil painting rather than water colors, if that helps you understand what I mean, but in case you don’t know about painting, you see, with oil colors, you can scrape the paint off if you make a mistake and paint over it (actually, you can’t scrape it completely off, because a little of the residue will impregnate the canvas, but almost all will come off and you can paint over it – that is, unless you’re painting certain light colors over dark colors that might bleed through, well, not bleed through exactly, but can be seen through the light color and maybe influence its impression a bit – not for all viewers, but those with … The delete key is the writer’s most important tool; same for software writers

— Jerry Weinberg, Roundtable on Technical Leadership


First Amongst Equals – How to Manage a Group of Professionals

by Tony in * one-offs

Oooh. A new David Maister book. (I discovered this through a review in the Journal of Business Strategy. I though I’d told Amazon to notify me of any new books by Maister, but obviously not.)

Managers often fall into the trap of looking for problems to be fixed rather than seekign successes that can be multiplied. This results in everyone being risk averse and cautious. It does little to encourage the vital task of regularly finding new ways to do the job better.


Understanding the Professional Programmer

by Tony in * commentary, * one-offs

This is quite an old book now by Jerry Weinberg (1982), and it has dated quite significantly – more so than Mythical Man Month which is a few years older.

Most of the programmers in this world were writing COBOL, PL/1 or raw assembler. And so many of the examples he gives don’t really translate well. (Although the extended example in “Say what you mean and mean what you say” could easily be translated in Java and show up in an Extreme Programming book). And cost analyses on the best way to teach computer programming when machine time was so expensive seem to come from an eerily distant past now.

But once we get into the middle of the book, much of the material tends more towards the “psychology” of programmers, which hasn’t really dated. And there are a few nice ideas that still haven’t really caught on. I particularly liked his idea that computer languages should be taught in pairs, with all the examples and exercises given in both languages. With natural languages the most difficult to learn is always the second. A third, fourth or even tenth language is much easier. The same seems to be true of computer languages also. So, teach people to be bilingual from the outset. Let them see how different languages would approach the same problem.

Although the book is on the surface aimed at programming managers, most of the articles really seem to be aimed at programmers who need to learn how to deal with programming managers. And, if anything, the problems he points out with the gap between programmers and managers seem to have widened rather than closed. As Weinberg writes: Code is to programming managers what dirty dishes are to a headwaiter. Once you have graduated from the garbage heap, you never touch the garbage again – even in jest.

The “Cost of Inadequate Software Testing Infrastructure” paper I linked to a few days ago had a chart that showed that the percentage of project time given to actually writing code had dropped significantly in the last few decades as more and more time went in to specifications, analysis, design etc. I doubt most managers read any more of the actual code that gets produced these days.

This is a book that treats coding seriously. Weinberg argues that contrary to popular opinion, now as much as then, coding is a valid profession, and a skill that takes years to master, not days or weeks. This idea has obviously had a resurgence recently with books such as Pete Breen’s Software Craftmanship, but it’s interesting to go back twenty years and see the articles that were being written then.

Probably not worth going out of your way to find, but worth a skim through if you find a copy.


Designing from Both Sides of the Screen

by Tony in * commentary, * one-offs

Most books I’ve read on User Interface Design support their theoretical approach with copious examples. This one takes the opposite approach. Most of the book is taken up with describing the evolution of an instant messaging client, and how its UI developed. This is made interesting because the software was developed simultaneously for Windows and for a PDA. However, I’d never heard of the product (Hubbub) before reading this book. This isn’t necessarily a problem, as there’s still a lot of useful ideas here (and as far as I’m concerned, the more books that reinforce the concept that most software is still really badly designed, the better), but I can’t help thinking that the book would have been more useful, or at least more interesting, if it was the story of the development of a product I actually used.


What Not How: The Business Rules Approach to Application Development

by Tony in * commentary, * one-offs

I spent an hour or so in MIT Coop reading this book, and taking copious notes. Date’s central thesis is that the trend in computing is always from Procedural to Declarative, from ‘How?’ to ‘What?’.

The biggest bottleneck in creating applications is turning the requirements into a functional system. His solution: eliminate the code, and merely state your business rules declaratively.

He spends quite a lot of time explaining how this is not the same as writing lots of event handlers in a database (they’re difficult to write, even more difficult to debug, and are usually database events (‘do something when this record is updated’), rather than business events (‘do something when an order is placed’).

I found his taxonomy of rules very handy. In the simplest form, all rules are either Constraints or Derivations.

There three forms of Constraints:

  1. State Constraints (Total Owed <= Credit Limit),
  2. Transition Constraints (You can move from Married to Divorced or Married to Widowed, but not from Widowed to Divorced, or Divorced to Widowed),
  3. Stimulus/Response (IF StockLevel – OrderedQuantity < ReorderLevel THEN reorder).

And two forms of Derivations:

  1. Computation (LineAmount = QuantityOrdered * OrderPrice)
  2. Inference (IF TotalOrders(c) > $100,000 THEN GoodCustomer(c))

If you can write a system that handles all these rules, then you can probably create 95% of business applications in a purely declarative manner.

I’ve been working for the last year on a framework that allows you to create database backed web sites mostly declaratively. You still need to do some Class::DBI set-up, although I’ve gradually made that less and less important, especially if you’re using a self-aware database, but after that you can create 90% of what you need for a reasonably complex site in a single config file. This book has given me lots of interesting ideas as to where I could take this next…