27 June 03 - 20:13Addicted to bugs

The product is an innovative one, but it has a history of so-so quality : the "two guys in a garage" situation. It did solve the right problem at the right time, and with a bit of luck it sold quite well for a while. Capital was raised; the coders promoted themselves to top management, hired themselves a CFO and a new development team.

The stage is set for a case study in the Addiction system archetype - this diagram.

To keep up with an expanding customer base which is demanding more of the product, the team needs to either ship new functionality or improve quality. They were hired by the founders and share some of the founders' cultural traits: they tend, on the whole, to be better at slapping code together than at writing and following detailed process documents.

Thus, shipping new (but somewhat buggy) features can be done relatively quickly, while the benefits of improving the code's internal quality, in the face of a rather important technical debt, only become apparent after a few days or weeks' dedicated effort, depending on the area of functionality.

Shipping new functionality tends to please customers in the short term, and also increases the technical debt, which makes the next ship-vs-improve decision more likely to fall on the "ship" side. Each time, the team swears that on the next project, quality will be job number one, but somehow there's always something that needs to be shipped urgently.

I've seen this situation many times. It's nothing new.

A recent insight, though, is that the label "Addiction" might apply more literally to this diagram than I thought. To a developer, shipping software is always thrilling - it can even be something of a "rush" of adrenaline at the thought that people will soon be using your creation. (I'm generalizing, of course - mostly it's what I remember from the early part of my career as a developer, plus inference from observing other developers I worked with.)

To the people who have most influence on the schedule and quality trade-offs - internal "customers" of the development team, often people in the marketing department - shipping a new version or a new product is nothing special in and of itself; just a straightforward business transaction. They may simply not realize that developers are rarely in control of themselves when queried for advice about whether to ship the most recent version ! The urge to ship overpowers all but the direst concerns of quality. The consequences are predictable.

Of course, people on the marketing and business side may suffer from their own "addictions", such as addiction to making aggressive promises to customers. Developers may not realize when the people who formulate requirements are not in control of themselves because of this addiction. Blindness to each other's addictions thus results in a feedback loop worse than each of the original addiction dynamics.

- Software Development - one comment / No trackbacks - § ¶

26 June 03 - 14:48Arguing both sides

Dave Thomas recently blogged about "debating with knives", extolling the benefits of being able to argue both sides of a position, reminding us that "very few things are black and white, and it’s nice to be able to acknowledge opposing points of view".

I've used the technique myself, once on precisely the same topic that Dave mentions - static typing vs. dynamic. I asked participants in a heated Wiki debate to switch positions, and argue each other's view.

Dave asks: "Could [this] take the heat out of the discussions we have about architectures, design, timescales, and so on ?" No question, if you think about it a moment.

There is always at least one thing that participants in a heated debate agree about - they agree to keep the debate going rather than part company to go do what they each advocate. If there always is at least one thing people can agree on, could there be more ?

In such a debate we say we are "convinced" of something, and we often say things to the effect that nothing could make us change our minds. If I reflect on past experience, I find that there are many things I was convinced of - downright passionate about - about which I have changed my mind.

As a very young boy I thought girls were at best dull and at worst repulsive creatures; I thought you had to be crazy to like beer. At one point I thought I knew all I needed to know about programming, and at some later point all I needed to know about leading projects. I learned later that there were realities I had been unaware of, and which caused me to a) learn some painful lessons (as well as some pleasant ones, such as about girls) and b) change my mind about these deeply held convictions.

So whenever I'm absolutely sure of something, I make a point of coming up with at least three things which, if they were true, would cause me to change my mind; I try to argue the opposite side in at least three distinct ways.

Highly polarized or "heated" discussions always suggest to me a lack of imagination on the part of the participants, whether the issues being debated are purely social and emotional or whether they are factual, abstract and theoretical.

- The Universe And Everything - No comments / No trackbacks - § ¶

25 June 03 - 09:42The Bus

Alan Green writes about Great Software Architecture Diagrams of Our Time, and introduces The Bus, with a fun game framed as a P.S. question: Where have you seen the The Bus before? Did it lie? Would you use it?

Fun game to play. I'll do a few. (I would use all of these, though not without serious considerations of their applicability to the current situation and of their limits.)

EAI middleware, such as TibCo, MQSeries. The Pitch: no more writing N-1 distinct connectors to wire each of the N apps your business uses to the other apps. The Lie: each app still exerts different and possibly conflicting constraints on the data dictionary.

These are perhaps more borderline...

XML. The Pitch: no more incompatible document formats. The Lie: no guarantee that Word's XML format has semantics compatible with anything other than Word.

Virtual Machines. The Pitch; write once, run anywhere. The Lie: every VM vendor wants their VM to have special feature that your programs depend on so you don't use the competitor's VM.

I like Alan's blog. The serious bits are usually interesting. The funny bits are hilarious. This was priceless.

- Blogversations - one comment / No trackbacks - § ¶

24 June 03 - 16:20Accounting

Recently, I've been reading Johnson and Kaplan's Relevance Lost, and Peter Block's Stewardship.

Previous to reading the Johnson and Kaplan, if you had asked me whether the topic of accounting was one worth learning about and investing attention into, I would probably have made a typical non-accountant's reply - no, the topic of accounting is dull as dishwater, and excepting perhaps the bare minimum of bookkeeping and accounting I will have to deal with to do business as an independent, I won't waste a minute on it.

Well, not the first time I turned out to be wrong about something, and not the last either, I expect. Relevance Lost chronicles the history of accounting from its roots in the Industrial Revolution to the present day. The history of accounting is relevant in understanding some of the business choices made today when it comes to managing projects (in the same way that a history of living forms spanning billions of years, and the lessons we've drawn from looking at that history, are relevant in understanding present-day choices about the design of software).

Two quotes in Stewardship stood out in the context of this newfound insight about the relevance of accounting practices:

Some managers have the budget or the willfulness to still go outside the organization to buy services that are available from internal groups, but since they have usually prepaid for the internal group through an overhead charge, they are doubling the cost of the services.

Think about an internal QA group providing testing (and other) services to a development team. It is sometimes the case that the QA group is providing no real value to the development team. The QA managers know too little about software development to hire effective testers, maybe. If the QA group was competing on the market, it would soon be outperformed by its competitors. But the way things are set up in the company's books, the development team "pays" for QA's services without even knowing about it, is not given a choice to obtain these services from some other provider, or even a say in which services it's getting. If it manages to get better QA outside the parent organization, it will show on the books as an "extra" expense.

Another quote:

The economics of patriarchy is having $3.50 in salaried overhead cost busy controlling, planning and watching $2.50 of direct labor engaged in making the product. When we then export the direct labor to a third world country, the $2.50 cost goes down to $.90 and the $3.50 remains untouched.

This, Block says, because the $3.50 is tied up in executives' pay and not even seen as a "cost" in the way that direct labor is seen as a "cost", because common accounting practices account for executives' salaries quite differently than for workers' salaries.

(Selfish Class link via Tesugen.)

- Software Development - three comments / No trackbacks - § ¶

19 June 03 - 16:19An Eccentric Programmer

I used to be a classicist in my practice of Extreme Programming. I always used index cards for planning. I bought them three packs at a time; I carried them around with me to work, to user group meetings, I used them at home for shopping lists.

Then I started on a consulting job where someone else was the XP coach, and they had chosen to use a program for handling user stories. I had no business questioning that choice, and I didn't. At some point I needed to create an information radiator to display the status of acceptance tests, and what was on hand at the time was Post-It notes.

Some changes were made in the organization, and I've ended up playing the XP Customer role for a while. Today I found that the Post-It note habit carried over to my planning practice - I ran an Release Planning session using Post-Its. And I caught myself thinking - "Hmm, these work even better than index cards."

It's official, then - I'm now no longer a classicist, but an Extreme Programming eccentric. An Eccentric Programmer.

- Extreme Programming - two comments / No trackbacks - § ¶

18 June 03 - 18:58Round Robin Pattern

We spend a lot of time sitting in meetings; making meetings more effective is a good way to improve overall performance. Many meetings, especially "status meetings", are excruciatingly boring - if not downright humiliating. Humiliating or boring meetings are not effective.

The problem ? A satus meeting's traditional format has the person who convened the meeting, a manager usually, work through a list of items. They are items of importance to the manager - not to the people attending the meeting as a group. Each item is usually about the work of one or more subordinates, who report their status to the manager for each item which concerns them.

Such a meeting is a waste of time to the persons not concerned by each item. It is humiliating when it is primarily arranged to demonstrate the manager's power over others; when it serves to show wasting other people's time as a manager's prerogative.

My preferred format for stand-up meetings or parts of longer, more formal meetings, is the simple but effective round-robin pattern.

People will stay involved in a meeting if the meeting serves them, not about the person who convened the meeting. Therefore, offer each participant, in turn, going around the table (clockwise or anti- according to taste), an opportunity to say anything she needs to tell the group. Everyone has the option to pass. Do not let one-on-one discussions develop unchecked; gently invite people to defer such discussions to after the meeting. Do feel free to "nudge" the speaker if he is taking too long, or otherwise facilitate the round-robin - always with a gentle touch.

Steve Smith offers some additional tips on meeting effectiveness.

- Software Development - two comments / No trackbacks - § ¶

16 June 03 - 19:47Matrimony as Poetry

Will you, Medium, take this message to be your poetically wedded partner ? I will. And will you, Message, take this medium to be your poetically wedded partner ? I will. It gives me great joy to pronounce you, Message and Medium, to be a Poem. You may now kiss.

Douglas Hofstadter, Le Ton Beau de Marot

- The Universe And Everything - No comments / No trackbacks - § ¶

12 June 03 - 22:06Activating attention

Hal Macomber's latest post is worth your attention. Mine was particularly caught by the following small bit:

Clear intentions and commitments engages the biological system of noticing -- the reticular activating system. For instance, we have an intention to get a new car. As the intention gets clearer about the type of car we want, say a two-door sports car, then we begin noticing what seems to be more sports cars on the roadway. Not that there really are more sports cars, just the reticular activating system allows us to see what has always been there. It works the same way for listening.

I don't know how well understood the underlying biological mechanism is. But I've certainly had many occasions to observe the "noticing" thing - also known as "mental set", and possibly related to the Stroop effect.

Quite often, what we think of as everyday "coincidences" are in fact instances of mental set at work. On a metro ride back from work recently, I was thinking of how team members in a gelled team often have nicknames for each other. This got me thinking in turn about how, though I will tolerate the common diminutive "Lolo", I prefer to be called by my own name, "Laurent". I looked out the window at that moment, and my eye was caught by a shop's sign which read "Electricité Laurent"; a name infrequently seen on store signs. Not coincidence, but a mind prepared.

Also recently, I was browsing through CVS diffs. I had been analyzing the patterns of failure, both software and human, that had led to a defect in a supposedly "completed" user story. The "bug" frame was strongly activated in my mind, and when I opened a Java file for a completely different purpose, I immediately spotted a rather classic mistake two-thirds down the page - a local variable with the same name as an instance variable, and that was being assigned to when clearly the instance variable was intended.

I see these as two instances of the same mechanism. In fact, I've been thinking about "mental set" and its role in a developer's work for a while now, and Hal's words about the reticular activation system grabbing my attention are a third instance.

The "mental set" thing is important. We learn, and we teach, particular techniques for testing, for project management, for software design, etc. These techniques, we say, make us more effective at finding bugs, at spotting signs of a project in trouble, at identifying opportunities for simplification.

But I think the techniques matter much less than being concerned with, being committed to, finding bugs or danger signs or simplifications. If we are on the lookout for these things, and equipped to recognize them, they will jump right at us.

- Private Life Of The Brain - one comment / No trackbacks - § ¶

10 June 03 - 21:40Failure and Estimates

Dale writes about The Benefits of Failure.

If you're always doing well by your own standards, you're not taking risks. If you're not taking risks, you're not learning anything. Your standards are set too low. Time to raise 'em. Contrariwise, if you're expecting unattainable perfection of yourself, all you will achieve is burning out early.

Another interesting application is the use of "two-point estimates" in Critical Chain planning, inspired by the Theory of Constraints.

One team I know is proud of having achieved a "96% level of accuracy" of their task estimates. Frankly, this scares me.

Many software projects, I suspect, go awry because project managers do not realize what is involved when a developer provides an estimate of the time required to complete some task.

A first complication is identifying tasks at the right granularity, i.e. small increments of work that can be completed without requiring significant "hand-offs" between developers or pairs of developers. Absent this assumption, there need not be any constant relation between the time spent on a task and the time to completion.

Assume that a task is really a task, i.e. it can be done, start to finish, by the same person or pair who estimated it. The traditional question asked of developers is, "How long would it take to finish this, assuming you are not interrupted by other work ?"

The problem is that the question is incomplete. The "how long" question can be answered fully for finished tasks - tasks that are in the past. But tasks not yet completed are in the future - and as far as the future is concerned, the one certainty we have is that we can have no absolute certainties. We have to deal in probabilities.

Implicity, the "how long" question also asks "...to some degree of confidence". If this is not specified, the developer will be free to interpret the question as best suits her.

Many developers prefer to err on the side of caution, and will only advance an estimates of five days if they think they could do the task in five days with a hangover and a hand tied behind their back. Many developers (and sometimes the same ones) are so keen to do certain types of tasks that they will say things like "This will only take a minute", even though most of us know that half a day is about the smallest sensible granularity for technical work.

In fact, if planning meetings leave the "degree of confidence" free to vary, I suspect that developers will use it as an adjustment variable to manipulate which tasks they get to do, and which they get to defer.

Two-point estimates look interesting because they remove this unchecked variation. Any task has an "impossible" estimate - even if you could code at breakneck speed, you couldn't possibly go faster than that. And any task has a "safe" estimate - even if your worst fears came true, you could still complete the task within that time.

In between are two useful estimates. The "50%" estimate provides a good baseline - if you were consistently producing 50% estimates, half of the time you would complete ahead of schedule, and half of the time you'd be late. Then there is the "aggressive but achievable" estimate - one that is much less dicey than just a fifty-fifty chance, but also such that if you added any more "padding" you would only marginally increase your confidence in the estimate. Critical Chain planning uses the "achievable" estimate to establish commitments from the persons responsible for a task. This means that, quite frequently, tasks will be completed late.

If that is not the case on your projects, then it's likely that developers are only providing "safe" estimates. If you are measuring "accuracy" of estimates, and rewarding developers for "accuracy", then it's all too likely that you are compounding the problem : developers will tend to "eat up" the remaining time when tasks complete early, as they usually will.

See why a 96% accuracy would scare me ?

- Software Development - two comments / No trackbacks - § ¶

07 June 03 - 09:11More CM Threads

Brian and Pragmatic Dave have contributed further "ways CM tools are important".

While his personal use is more in line with what I call the "Ariadne's Thread" aspect of version control, Brian mentions sifting through change logs at work to spot patterns in how code files are edited. Dave says that if a file is in CVS, then he can access it for modification from any of his small fleet of computers scattred through the home.

Responding to my RoundTable post, Bob Lee reminds me that CM tools have evolved considerably over time, and notes that this technical evolution is now enabling new and more effective behaviours - and the Agile/XP disciplines rely to a large extent on this dynamic. Summing up, he adds "Automating the bookkeeping and making the CM process simple, bullet-resistant and habit-forming has changed the game very much for the better. "

Are you using version control and configuration management tools in ways that haven't been mentioned so far ? Please comment (or trackback).

- Blogversations - No comments / No trackbacks - § ¶

06 June 03 - 00:00Agile Configuration Management

Version control, and more broadly "software configuration management", are important technical topics in software development. Steve Berczuk and Brad Appleton are hosting a RoundTable over at StickyMinds to discuss it.

One characteristic of important topics is that nobody agrees on an exact definition for the basic term – you see this with the very contentious word "architecture", and it is almost as true for configuration management.

Some of that confusion probably stems from lumping together more than one software discipline under the label "software development". Pete McBreen, for instance, argues that we should make an explicit distinction between "software engineering" on the one hand, a style of development applying to very large projects (hundreds of developers) in safety-critical domains; and a much more commonly applicable discipline of "software craftsmanship". Most Agile projects squarely belong in that latter category.

Much of the concerns commonly associated with software configuration management, SCM for short, originate from the large-project view of software development; for instance, SCM is viewed as crucial in managing multiple versions of the same software differing in minor ways; establishing traceability from requirements to lines of code; managing formal workflows for change requests; ensuring compliance with documented processes; extracting and publishing statistics, metrics and reports; and coordinating the efforts of large teams.

At the same time, if you ask any experienced developer about SCM, or version control, she will tell you that even if you work by yourself and are interested in none of these things, you would be foolish, verging on suicidal, to start a project without availing yourself of a version control system. It needn't be anything fancy, CVS or SourceSafe will do; but you have to have one.

This suggests that the "software engineering" view of such tools isn't the whole story. On reflection, we can think of one fundamental role for version control that is almost systematically overlooked, and one more in keeping with the "software craftsmanship" view : experienced developers, software craftsmen, use the version control tool as their Ariadne's thread.

That's what developing software feels like. You are in a maze of twisty little passages, all alike. Any coding task can be accomplished in one of several ways. This is always true, regardless of how much you are constrained by an idea of what the "proper" low-level design for this particular portion of the code should be. If you are iterating over a collection of elements, for instance, perhaps you will have a choice of using an iterator method, or element indices. Perhaps it makes sense to consider iterating backwards instead of forwards, though both might yield the correct result.

You use version control because it tells you where you have been. As you make your way through the maze of twisty little decisions – all alike – that software development always turns out to be, you unspool your thread by "checking in" – saving your source code to the version control tool – at regular intervals when your application is in a stable, reliable state. (For an Extreme Programmer, this will of course be when all unit tests are passing.) If you get hopelessly lost, you know that you can always "roll back" to a state known to be good, and start again from there. Like unit tests, the primary benefit of version control is the degree of confidence it provides.

This is nothing, of course, that you couldn't achieve by regularly backing up an archive of your source code. One crucial difference is that version control systems give me, the programmer, a visibility into the past history of their source code that is conceptually consistent with the way I program : rather than see N previous versions of the whole project, within which I must then pick out a source file I'm interested in, I am directly confronted with a list of source files, for any one of which I can view N prior versions.

There are further capabilities of version control tools which a backup doesn't provide, in particular in supporting the work of multiple developers; capabilities which are also rarely mentioned in discussions of SCM.

A code repository provides a team of developers with one single, authoritative, shared version of the source code. If this authoritative version is treated with respect, it can become a stable and easily reproductible baseline. Each successive modification can then be viewed as an increment of tested, known quality code added to this baseline.

Also important is promoting visibility. With fine-grained commits, and a rule that "if it's not in the repository, it doesn't exist", any design or implementation decision becomes reviewable by potentially the whole team the instant it is made. If you introduced a defect while coding feature Foo, the diffs will show precisely what the immediate cause of the defect was (e.g. off-by-one error), and will help a lot in figuring out the indirect causes (e.g. the commit was for a "quick fix" to a reported defect, and we forgot to write a new unit test exposing the defect before fixing it).

- Software Development - No comments / No trackbacks - § ¶

04 June 03 - 17:09Hiring and testing

A lot of the energy invested in hiring technical people seems to go in the up-front stages: the want ads, the interviews, the auditions, etc. One of my favorite resources on the topic is Johanna's Hiring Technical People blog, and so far Johanna has chosen to discuss mostly these stages.

My experience seems to confirm this bias: getting hired is a long and time-consuming process, which - in spite of France's mandatory "trial period" of three months for most white-collar workers - ends the minute you have set foot in the workplace.

Only once was I terminated during a trial period, very early in my career - the first employee job I ever held, actually. Of all the "new hires" I've ever worked with, none were ever terminated during a trial period. Strangely enough, many of them were not competent for their position in my opinion, and in some cases I was asked for that opinion by upper management - but they were kept on nonetheless.

This makes a weird sort of sense - after having gone to all this trouble to select a "suitable" candidate, it's a tough decision to show them the door after one or two weeks on the job. "Lack of qualified candidates" is a reason I've often heard for not letting go people who had been found wanting during a trial period.

I'm tempted to see a parallel here - hiring is a process in which much energy is invested in the early "design" stages, to try and make sure no mistakes are made, because mistakes are costly to correct later (and perceived as all the more costly for having invested so much energy). The "testing" stage is deferred as long as possible, most often until it's too late.

I wonder what would happen if we drastically reduced the effort spent on the up-front design stages, and hired candidates on the basis of whether their prospective coworkers like them, and whether they think they're qualified to solve our problems. Then very early in the trial period, we'd expect them to start contributing, even if on rather small tasks.

This could even be a win-win proposition - people would be earning money during the hiring process, employers would (hopefully) be getting some work done or getting some useful feedback for that money.

Just a thought...

- The Universe And Everything - two comments / No trackbacks - § ¶

02 June 03 - 09:50Legitimate disinterest

Some time ago I wrote about the Principle of Legitimate Curiosity: if there is something about a piece of code that matters to the customer - a behaviour we are legitimately interested in testing - then we are justified in exposing this behaviour in a public interface.

There is a converse Principle of Legitimate Disinterest. When I am testing some functional aspect of a program, I should be able to ignore anything about the program that is not relevant to that functional aspect.

A particular case, and a first example, is the case of tests that depend on their executing environment. If I am testing, say, a program's search capabilities, then I am not interested in the specific details of how the program has been installed on my machine - which directories, and so on. The test script should make such details irrelevant, for instance by computing all the relevant directory paths automatically. Not only automatically, but also invisibly: these details should not appear in the main text of the test script. (If the tests are written, say, in Java, then it is relatively easy to "abstract out" such details to a superclass.)

The principle applies at "higher" levels. Take the example of a server program which is "cross-platform" in that it can be run against several RDMBs, e.g. Oracle and Sybase. By definition, most of the behaviour of such a program will be specified without regard to the particular database. A "search" feature will be specified in terms of "the system returns all records which match criteria X, Y, Z". It will not specifically mention Oracle or Sybase.

If that is the case, then the test should be equally "cross-platform" : its text should not explicitly refer to a particular database.

If there are features which are tied to a particular database server, then they should belong to a separate test suite, and a separate component. Let's say that the customer requests a version of the program which can be installed and run on SQL Server as well as Oracle and Sybase. Although concerned with a technical aspect of the system, such a feature definitely has business value : it doubles the size of the market for our server software.

How should one formulate the feature request (aka user story, or whichever term you prefer) ? The feature has nothing to do, particularly, with the existing search features, or the features of the installer. Either the search feature works, or it doesn't; if we find ourselves saying, "the search feature should now work under SQL Server", we are mixing up something expressed at an abstract level (the search feature) and something expressed at a platform level (the fact that we can connect to SQL Server).

The appropriate description of such a feature would therefore be "the now supports SQL Server in addition to Oracle and Sybase", where the is whatever enabled us in the first place to support more than one platform.

Combined, the principles of Legitimate Curiosity and Legitimate Disinterest drive the design and architecture toward modularity and abstraction.

(The PLD has further practical consequences, in particular on the kind of tests we introduce preliminary to correcting a defect, on how easily we can run regression test suites, and on how to organize such suites. I'll revisit these topics later, if I can order my thoughts on them.)

- Testing - No comments / No trackbacks - § ¶