Hiatus

I’m flying to Perth for Christmas, so things will be quiet hereabouts.

Posted in Diary | Leave a comment

Oops

So I’ve started working on exercise 2A. I was about an hour in before remembering I’m supposed to be tracking every defect, no matter how minor. So I have two in the defect log so far, both with estimated repair times.

Otherwise, uneventful so far. Writing a physical LOC counter is pretty straightforward. A logical counter will be more interesting.

Posted in PSP | Leave a comment

Exercises R1 and R2 are done.

Remarkable how productive one can be when the internet is broken.

My thinking for exercise 2A (which is based on R1 and R2) is to build a SLOC counter using LPeg and Leg. This exposes what is to me a hole in the PSP 0.1. How does one account for researching time? Does it go under Design? In a more elaborate PSP I can only imagine that it deserve its own heading.

Posted in PSP | Leave a comment

Agile plans

One of the books I have going at the moment (I tend to multi-task books) is Mike Cohn’s Agile Estimating and Planning, a fairly concise take on how to obtain these qualities from agile projects.

I think that the central allergy of agilistas is to the Gantt chart, that famous diagonal artform of ribbons and spilling arrows. The Gantt chart is notorious for its inflexibility in practice and in giving a false sense of certainty.

Yet, despite the central messages of agile methods pointing to the ability to pivot the project in response to customer contact, planning is still a part of the process. It’s just wrapped up in low-precision formats.

Currently in A Discipline for Software Engineering I am working through Chapter 3 on planning. Here are the 4 “general things you need from a plan”, according to Watts Humphreys:

  • Job sizing: How big is this job, and how long do you expect it to take?
  • Job structure: How are you going to do the work? What will you do first, second and so on?
  • Job status: How do you know where you are? Are you going to finish on time and are the costs under control?
  • Assessment: How good was your plan? Did you make any obvious errors, what mistakes should you avoid in future, and how can you do a better job next time?

All these questions don’t just apply in the PERT-and-Gantt world Humphreys came from — the IBM mainframe and DoD universe. They’re also answered by agile practices:

Plan requirement Agile practice
Job sizing Planning poker, story points, ideal days
Job structure The planning game, backlogs
Job status Velocity, burndown charts, kanban boards
Assessment An infinity of blog posts :D

Burndown charts, coming from the Scrum methodology, have a companion in Humphrey’s world of the Earned-Value chart. You might think of EV as a more elaborate version of burndowns, with all the good and ill that entails.

Similarly, planning poker can be seen as a cut-down version of the Wideband Delphi method introduced by Barry Boehm. Pair programming can be seen as a kind of code review. And so on.

Truly, there is nothing new under the sun :D

Posted in PSP, Software Engineering | Leave a comment

Exercise 1A completed.

So I’ve just finished exercise 1A from A Discipline for Software Engineering.

Switching to more idiomatic Lua (see my last post) made a big difference in the subjective easiness of the work; but I still spent almost as much time in the Test phase as I did in the first design.

Nevertheless, the code now runs and passes the miniscule test suite based on the data in the book (Table D5). I wonder whether it would have been worth to write a fuller suite to cover the functions I put together — for example, the std_dev function is tested directly by the suite, but not the avg or sum functions.

I’ve also started putting my work online at Github. Pretty rudimentary stuff, but at least it gives me a motivation to do the exercises if I imagine that somebody is checking out the code & logs and going over them.

For testing I used the lunatest package. Missing from lunatest is a capability to provide precision deltas on the assert_equal function. In ADFSE, the standard deviations of the sample data are given to 2 decimal places and are rounded. Lua doesn’t have rounding built in, so it was necessary for me to include a little rounding function to equalise the results. Other testing frameworks I’ve seen allow you to pass in a delta value — a degree of permissible variance that still counts as “equal” — which saves a lot of the bother.

So that’s it. I’m looking forward to the next exercise.

Posted in PSP | Leave a comment

Exercise 1A

So I’ve been working on the first of the PSP exercises. The requirement is to write code that calculates the average and standard deviation of a linked list.

My first attempt hasn’t ended in failure, so much as the realisation that I took the wrong approach. I’ve marked this down as a design defect in my error log.

The emphasis really ought to be on the standard deviation and not on the data structure. I’m writing in Lua, a language which among other things includes a flexible standard data structure called ‘tables’, which can at various times behave like arrays, hashes, stacks, queues and so on.

My next revision of the code will focus on using tables as-is, rather than bodging up a linked-list structure composed of tables with two elements. I expect it will probably be much easier to write, too, due to Lua’s support for easy iteration over table structures.

Posted in PSP | 3 Comments

Phew

Both of my regular readers (I’m just kidding, nobody reads this blog regularly) may recall this primal scream at “high fashion”.

But it’s not all bad in fashion-land. Apparently some photographers actually play to their model’s strengths. For example, see some relatively recent photos of Clare Venema below the fold and compare them to the previous batch.
Continue reading

Posted in Beautiful Women | Leave a comment

iWork Numbers 2008 can’t deal with time durations

A very annoying discovery.

One of the common complaints about the Personal Software Process is that there’s a lot of data-entry and number crunching. The data entry I can’t do too much about (though compare Hackystat), but number crunching is something that computers are supposedly good at.

So this afternoon I spent a few hours running up a simple spreadsheet for the first exercise of ADFSE. The first exercises require students to use the “PSP0″, or Personal Software Process level 0. In PSP0, there are three documents/forms: the time log, the defect log and the project summary.

There are other examples of these forms about on the internet for various tools (mostly Word and Excel), but I wasn’t really satisfied with any of them. In particular, most of them a) slavishly recreated the appearance of the forms in ADFSE and b) don’t do any calculation for you.

So I decided to create my own spreadsheet in Numbers. When it’s a bit more battle-tested I might upload it for others to use.

Naturally it has the benefits of spreadsheets (easy calculation of related variables) and the drawbacks (non-robust data storage, needing a file per-project). But most annoying to me is that Numbers 2008 doesn’t have a notion of a time interval. The PSP time log format is to enter a start time and an end time, then to subtract to determine the number of minutes. Numbers can’t perform this calculation because it has no duration type to express the result of that subtraction into. Apparently Numbers 2009 has something like this, but I don’t feel like spending money on a perhaps.

I might be stuck redoing the spreadsheet in openoffice. Damn yak-shaving.

Posted in PSP, Rants | Leave a comment

An interview with Watts Humphreys

Grady Booch spent 18 hours talking to Watts Humphreys about his life and life’s works. Definitely worth a read — set aside a few hours.

Posted in History, Life, PSP | Leave a comment

Discipline

I’ve decided to work through the exercises in Watts Humphrey’s A Discipline for Software Engineering, to see whether they’ll help me to be a better developer. With any luck I’ll remember to update the blog with my findings.

A Discipline for Software Engineering (let’s called it ADFSE) outlines the “Personal Software Process” or PSP. Essentially Humphrey took what was “best practice” for large software projects in 1995 and boiled it down to a process for single programmers. The book outlines a mix of practices and principles; and provides exercises to be carried out.

I first saw mention of the ADFSE in two different books by Steve McConnell, that incomparable genius of concise summary and approachable anecdotes. He mentions it both in Code Complete, 2nd Edition and in Software Estimation: Demystifying the Black Art. I figured that this was as good an endorsement as any.

In some ways the key innovation of ADFSE is to turn software process inside out. Normally software process is seen something that is imposed in a top-down from outside the developer. It is placed between developers and other developers, and between developers and their work. A lot of developers chafe at process for various reasons. For one, it can be a token of a local management-by-fiat culture. It’s also often very boring to write endless reports — coding is much more fun.

ADFSE instead works from the developer out. The developer imposes the process on their own self. This turns it from a matter of fiat and punishment into one of self-discipline — hence the book title.

I had been putting off lashing myself to the pole on this one because there’s few things more embarrassing than making a loud public noise and then not backing it up. But my decision has been given new impetus by the death of Watts Humphrey in the past few days. A remarkable pioneer of the computing world, he was a titan who served full careers in both industry and academia. He’s a great loss.

Posted in Books, PSP | Leave a comment