31 March 03 - 00:48Shark Tank

Thanks to Jim Bullock over on the Shape forum, I've just come across Computerworld's Shark Tank column.

Horror stories from the field - some good, some not. After a quick sampling, an unknown fraction of them seem to be your usual "users are clueless" testimonials to the enduring power of human stupidity. A few are merely cute. However, there are some gems in there which attest to a keen ear for systematic mismanagement, or simply bad systems management, of the kind I've grown interested in.

Suggested exercise for people slightly clued in about such things - pick one of those pieces, and attempt to understand the various mental models involved, and possible flaws therein.

Last note - it probably means something, though I don't quite know what - the first thing I thought after reading a few pieces I liked was, "Is there an RSS feed for this ?" It turns out that there is - here.

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

29 March 03 - 10:13Batches

Sergey Vlasov had a string of thoughtful observations these past few days (March 25-27 - Sergey is living proof that you can blog without blogging software). One in particular caught my attention:

"Rare meetings are bad time to introduce new ideas, cause everybody have accumulated they own thoughts and want to talk more then listen."

I've been reading The Goal recently. Not for the first time I found myself reflecting on how various industrial metaphors such as "inventory" and "batch sizes" can transpose, to powerful effect, to other domains. When I read Sergey's "rare meetings" observation, I immediately thought "reduced batch size".

We have an intuitive understanding that any discrete event, such as a meeting, has a minimum (or "incompressible") cost. Say it takes 5 minutes to begin the meeting, while everyone gets seated, takes out a pen, blows his nose or whatever, and then 5 minutes to disband the meeting and return to work. A meeting that lasts 10 minutes has a total "cost" of 20 minutes, which does not sound very efficient. A meeting which lasts 50 minutes will "cost" only 1 hour, which sounds more acceptable.

So, for an equivalent time in discussion, it's half as costly to have one 1-hour meeting every week than to have one 20-minute meeting every day.

But "less costly" doesn't mean "more effective". I've experienced what Sergey points out. At one meeting per week, we have time to "accumulate" issues. Things that have been on our minds for a whole week seem more important, and we discuss them at more length. If we had urgent issues, they have had time to become even more urgent, particularly if the meeting is the only occasion to bring them up in a group. Important issues that have come up in the meantime, but are less urgent, will not get discussed in this meeting for lack of time : they'll have to wait until the next meeting, by which time they will have become urgent.

The more this happens, the longer the meetings go on and the less effective they are, which all but ensures that we experience them as a "waste of time", and suggest that perhaps we might do with one every two weeks...

I regularly hear from people who have experimented with daily meetings such as Scrum ("Daily Scrum") or XP ("Stand-up meeting") recommend. With no exceptions, everyone says that such meetings are incredibly effective in getting issues solved quickly, gathering momentum within the team, etc. My experience is about the same, although I prefer brief, informal "huddles" to formal meetings.

Another area in which I've experienced similar effects is in "batching" minor corrections to a software product. Often, our intuition is that our work will be more efficient if we don't fix minor defects as soon as they are reported, for instance by a user, but instead collect incident reports in, say, a "bug database" and set aside a longer period of time to work through the reports and fix them one by one. Meanwhile, we are free to continue with development work without interruptions; batching thus reduces multitasking.

This often has the same kind of downside as batching ideas or issues for meetings. For instance, if the product is used by many users, the longer we delay issuing a fix for a defect, the more likely it is that several users will report the same defect, which will make more work when we get around to working through the list. Even if the product is still "in development" rather than in use, there is also the risk that further development on a product area which already has defects will make it more instable - thus more likely to generate further incident reports.

Of course, there may be a lower limit to the batch size, for defect fixing or for meetings, below which reactivity degenerates into firefighting.

All this suggests that there are trade-offs involved in batch sizes for various processes applicable to our work on software projects - which is good news, because wherever we find a trade-off, there is a possibility to make smart management decisions.

If you are dissatisfied with one of your processes - meetings, correcting defects, whatever - and you seem to see a trend toward increasing batch size, try going the other way for a change: reducing the batch size drastically. Have 10-minute daily meetings, or try fixing defects as soon as they are reported.

What other processes are there in software development work that involve varying "batch sizes" ?

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

28 March 03 - 09:44Modularity and reuse

Alan Francis has some interesting (though somewhat incipient) thoughts on reuse and modularity, vs. "rewriting" and "reinventing the wheel".

This "reuse" things has a few aspects, off the top of my head, that are rarely separated with anywhere like the appropriate level of precision.

One is granularity : what is the size of the "modular component" involved in a reuse operation ? Alan quotes Richard Gabriel, who mentions databases. A database is a rather large component. A class, or a small cluster of classes, is not quite the same thing.

It's always more worthwhile to reuse large components, but always more difficult because they don't necessarily fit well, along the whole of their published interface, with the existing system's design. Conversely, it's easier to reuse a class or a cluster of classes, but there might be more work to do to fill in the missing functionality.

Then there's the distinction Alan draws between reusing the component "as is", or reusing the idea, the blueprint. Modularity is really a matter of abstraction (Richard Gabriel says "separation"), giving a distinct name to a set of related responsibilities that work well in synergy with the other abstractions in a system.

Gabriel argues that an arm, for instance, isn't modular in the sense that an ideal "modular component" programmed for reuse is modular. "Arms look like modular parts, but they aren't. Each is custom grown for the person who hosts it. Within each persons genetic code is the knowledge of how to grow an arm in place, custom fit to the body being created concurrently."

Design patterns work more or less that way in Extreme Programming - you know that a Composite or a Visitor is a good solution to a particular design problem, but you don't plunk down a Composite or a Visitor in the middle of your existing code : you grow the pattern, bit by bit, as you refactor code that is added in "functional layers" to the system, implementing feature after feature.

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

28 March 03 - 00:01CSS Problems

It has come to my attention that the "new look" for the blog doesn't display correctly in IE6. Just ignore this entry if you're not interested. (more)

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

27 March 03 - 08:36Etudes, Kata, Practice

PragDave and Andy have been going on about coding/design exercises.

Bill Wake has lots of wonderful games for programmers, which are also good exercises or kata for some of the moves in Extreme Programming. I've also used Joshua's XP playing cards to good effect, for a more conceptual sort of exercise.

Ron Jeffries calls them Etudes.

I am particularly interested in études, kata or exercises which focus on the human, collaborative side of Agile software development. Especially because we may easily think we don't need any practice in these areas.

What are good kata for perfecting XP's "Whole Team" practice ? The question may sound silly - just have your software projects' customers sit with their programming teams, and that's that. But Whole Team can only be effective if accompanied by a gamut of behaviours that take advantage of the interaction between customer and team.

What are effective protocols for asking questions to the customer ? For negotiating details of a user story's scope ? For announcing schedule problems ? (The issue of Cutter IT Journal I mentioned yesterday has a wonderful article on "Old Game" vs. "New Game" schedule negotiation.)

I work with a European group, the System Thinkers, to practice some specific problem-solving behaviours.

It turns out there is even a name for groups such as these, of people who exhibit intense dedication to the intentional practice of the professional behaviours they depend on: Communities of Practice.

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

26 March 03 - 10:59Dependencies

In response to Becky Winant's essay on requirements, Frank Patrick says of the Critical Chain planning method, which he favors:

"The typical critical chain planning process quickly moves to the building of the project's dependency network, so that, even if details of how components are to be delivered are fuzzy, at least the required interactions between components can be defined. In this way, the project is understood not as a sum of components, but as a system of interdependencies supporting the project objectives."

I've only begun digging into the basics of the thinking behind Critical Chain, but I was puzzled by this emphasis on dependencies, which Extreme Programming strongly de-emphasizes.

For instance, here's what James Grenning had to say on the topic in an article on migrating to XP:

"Usually a project manager coordinating a team's work with other teams spends a lot of time juggling priorities and figuring out task dependencies. On the XP team, dependencies between features were almost nonexistent. We built features in the order of customer priority, not internal software framework order dictated by a BDUF (Big Design Up Front). The team was agile and able to adapt to the other subsystems' changing needs."

I can't decide whether James and Frank are in complete contradiction or in violent agreement.

One all too common way of planning a software project does involve breaking down the work into technical components (as opposed to features). So many weeks for the persistence framework, so many for the domain model, so many for the "presentation layer". The required features of the system are supposed to "drop out" of the integration stage when the components are assembled.

Many Agile processes recommend breaking down the work exclusively according to "features" - new capabilities available to end users.

Extreme Programming recommends that technical dependencies should play almost no role in planning the work to be done. It seems to me that if this is the case, business dependencies (in the form of priority ordering of features) will be reflected in the planning.

If we are to understand a software project as "a system of interdependencies supporting the project objectives" - a chain of mutually supporting, intermediate objectives in pursuit of a larger, farther off, overarching obective - then technical dependencies are mostly irrelevant. The objectives of a software project are usually not technical, i.e. the software is not built for the sake of building the software, but to achieve some other business objective.

So I'm pretty sure that it's not technical dependencies which are worth focusing on in a project plan. I'm less sure how well XP, or various software development processes, measure up to handling business dependencies.

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

26 March 03 - 10:40Critical Chain in Cutter

Cutter IT Journal: March Issue

Synchronicity strikes again; the March issue of Cutter IT Journal, which I found in my mailbox this morning, is about Critical Chain Project Management.

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

25 March 03 - 09:03Learning styles, project styles

There's no reason why you should expect your brain and mine to work in precisely the same way.

No one really knows the process by which a "standard issue" brain becomes, in the first few years of life, a unique and complex human personality. But my readings in science and in philosophy suggest to me a deeply contingent, opportunistic process. A process which, to be sure, admits of major regularities - I've witnessed it at close hand in three different children by now, happily all three of them on the "main sequence" which has language fully developed betwen ages one and three; but nevertheless a messy one with huge differences from one instance to the next which nothing seems to explain. (How come the first words child #2 ever spoke, after "Papa" and "Mama" were the colors - red, blue, yellow ?)

So it does not surprise me that "boxes and arrows" leave me totally befuddled when it comes to grasping the structure of a program, while to other people they are a lifeline; or that I am much more at home with the raw source code (and, if at all possible, automated tests) while to other people it appears as understandable as a snow crash.

To one, rather simplified, model of viewing such differences, I am primarily kinesthetic in this regard whereas people who prefer UML are primarily visual.

Now, here's a thought. If your project team is formed primarily of people who favor a visual processing style in their work, what would you expect to happen if you chose for your project a process model which involves mostly the kinesthetic modality for conveying design information, such as Extreme Programming ? Conversely, what if your project team has a lot of people who favor kinesthetic processing, and insist on RUP or some other process which mandates "visual modeling" prior to any major design decision ?

I would expect a project team to be much like a person, and when it performs as an integrated whole - if it ever does, a topic I'll have to come back to - to have its own unique "style" of acquiring and processing information. The amount of visual, kinesthetic, conversational etc. activities which lets that particular team perform best is unlikely to be quite the same as any other team's.

- Private Life Of The Brain - two comments / No trackbacks - § ¶

24 March 03 - 09:53Legitimate curiosity

A question often asked by people new to Extreme Programming's brand of unit testing is, doesn't all this test code calling into my components violate the principle of encapsulation ?

I want to posit a principle of legitimate curiosity. If there's something about a component that we want to test, something in which we are interested for legitimate reasons, then that something may be part of a public interface. As XP requires that (almost) everything should be tested, (almost) everything is part of a public interface.

This causes chagrin to some who think, for good cause, that the public interface of components should be as restricted as possible, in application of sound principles of encapsulation.

In the french Extreme Programming mailing list the other day, the following code was suggested as an instance of - possibly illegitimate - curiosity about a component. Should Button.Color be made public for the purposes of testing ? Should we declare the test code as "friend" (a C++ idiom) to the code under test so we can keep it private ?

> // ... set up some context
> // ... perform some GUI action
> check(clRed, confirmButton.Color); // verification

I would probably not do this. Or at least, I would think of it as a refactoring waiting to happen. Seems to me that if we have many tests of this kind, we run the risk of losing sight in a "semantic fog" the reason we are interested in that button's color.

To recap XP's rules for "simple code"; simple code is that which...

• ...runs all the tests


• ...distinctly expresses every distinct idea


• ...expresses any idea once and only once


• ...expresses nothing superfluous

Now, why are we testing that some button is displayed in red ? Because that is important to our customer, who is in urgent need of it.

All right, but what is the nature of this urgent need ? "Whim" cannot be admitted as a legitimate justification for a customer's functional requirement, without betraying both the developer's and the customer's rights. If something is worth implementing, it must be possible to articulate why that something has value to the customer.

"Because when the operator presses this button, the system sends the file to a government agency, which has legally binding consequences for us. We have to be very serious with that."

We're getting somewhere. So there must be an idea which our code isn't yet expressing: 'an action which has legally binding consequences'. To my way of thinking, we will eventually end up with two distinct tests:

- a functional test which requires that the action associated with the "Confirm" button on screen XYZ is identified as having legally binding consequences;

- a unit test on the GUI components, independent of functional testing, which verifies that when a button is associated with a LegallyBinding action type, it is displayed in red on an operator's screen.

With the concerns so separated, the code is better encapsulated, more modular, has less coupling. The code which decides whether the button should be painted red is moved from the GUI layer, where it resided originally, to the application layer.

This separation, with its MVC flavor, exists only in latent form in the original test. It is a matter of pragmatic choice whether, after many refactorings, the original design evolves into the latter, and it hinges on how often the "button X should be displayed in red" requirement pops up - on how much legitimate curiosity we have about the color of buttons.

This is how XP deals with the apparent paradox regarding public interfaces. When interfaces grow to long lists of methods, it is almost always because we are dealing with two distinct ideas which can be separated into distinct classes. Rather that shrink the public interface by classifying many methods as "private", we shrink it by splitting the original component into smaller ones which express distinct ideas, and which have mostly-public interfaces.

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

22 March 03 - 15:25The power of naming

On The Naming of Things

The act of naming is one with its very own power and mystery. Among the first important choices parents make for their child is the child's name.

The names of things and people exert subtle influence on how we think of them. The names of things suggest boundaries to their nature; they bring to mind whole constellations of metaphors ready for use; and so on.

Extreme Programmers pay a lot of attention to the naming of the smallest things in programs - classes, methods, local variables. "Intention revealing" is one of the catchphrases we use to underscore the importance of names.

I believe, and Simon Cozens illustrates, that this importance extends all the way up and down the levels of detail that software projects deal with.

It's even fun trying to think of all the levels... Job titles. On-screen components. Directory names. Computers ?

Possibly computers are a borderline case of a distinction I think exists but I can't at the moment articulate properly - when naming stops having to do with function and starts having to do with semiotics; with what the name suggests independent of its "official" meanings.

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

21 March 03 - 10:42Robo-nagging

Captology, via Learning Circuits.

"The Stanford Persuasive Technology Lab creates insight into how computing products -- from websites to mobile phone software -- can be designed to change what people believe and what they do."

Nice hook. Interesting to me because as a consultant my job is to influence what people believe and what they do, at their request.

Upon closer inspection, disappointing: one of the examples they have on offer of this wonderful "technology" is an automated system to nag employees about washing their hands after using the toilet. (As a favorite humorist, Pierre Desproges, was fond of saying, I prefer to wash my hands before.) Another is actually one of these annoying "nag screens" found in shareware products, yet another a dialog in a personal finance program which pops up, with sound effect and cheesy party balloon graphics, when you're done balancing your books.

Nagging and motivational forced cheer. Let's hope not too many managers hear about this lab's flavor of Captology.

On the other hand, I've also come across a software product which seems more relevant to the idea of "changing what people believe and what they do" - Consistency, a tool which improves your daily habits by making more visible your degree of consistency in executing recurring tasks.

- default - No comments / No trackbacks - § ¶

20 March 03 - 14:53Fatter at the bottom

Chris Lightfoot

Every so often I like to take a cheap shot at the term "architecture" and its cognates, as applied to software work.

It's nice that, here, I can let someone else do it for me:

"Alexander's book, of course, is about architecture-- the real sort, not `software architecture' or any of the other euphemisms which have been made up in recent years to cover up the fact that programming is basically a pissant occupation. As we know, 'If architects built buildings the way programmers write computer programs, the first woodpecker to come along would destroy civilisation.' Which means, I suppose, that it's a good idea for programmers to learn from architects. That said, a long time ago I talked to an architect-in-training, and asked him about how architects are trained to work with structural engineers. The answer? They aren't, to a first approximation. They are encouraged to draw buildings which are fatter at the bottom than at the top, and told that if they do that, the engineers will probably be able to make them stand up."

For a kinder thought, check out the links Peter Lindberg provides.

- default - No comments / No trackbacks - § ¶

19 March 03 - 09:45Fun: for or against ?

Against: Judith Mair - see "Don't mention fun"

For: Andy Hunt - see "Are we having fun yet ?"

See also a post by Ton Zijlstra, who by the way sounds like a natural for Bookshelved, the site I steward for people who like to have fun with books.

"When we started out we ran the company according to the so-called 'cool' approach adopted by most of our competitors. This meant that we started work at around midday and drank beer in the office. We ended up working most weekends and half of most nights. In the end we were all exhausted and ended up with a lousy product," Miss Mair said.

Counters Andy: "As Pete McBreen is fond of saying: it it's not fun, you're not doing it right. Too many people that I've met are quietly ashamed of their projects---maybe they blame their management, or their tools, or something else in the envrionment. They are certainly not having fun."

As fine an imaginary dialogue as I can conceive of, but have you noticed how they're talking about very different things ?

Mair's more outlandish, quasi-military ideas about work are easily ridiculed, but I seem to discern a core concern which is entirely legitimate: a concern with managing the boundaries of the work context, to keep it from interfering with the personal, the intimate, the human.

To me, enforced "fun" such as motivation-building offsites or mandatory "cocktails" outside business hours are just as horrible as having to wear a uniform would be.

Andy's idea of "fun" adresses something else entirely; it has to do with feeling that what we do at work, within a team, is significant to someone; that it matters. Do you feel good about your work ? Do you feel uplifted by it ? Do you feel that it adds to the world ? You can't help but have fun if that's the case. If the work is good, and you share that with others around you, what happens is the essence of fun - you connect with these others as people, as humans.

The problem with Mair's idea is that you can't check the human at the door when you come to work, and only bring the worker inside. I'll side with Andy.

- Private Life Of The Brain - No comments / No trackbacks - § ¶

18 March 03 - 10:22The job non-market

Salon.com : Take this tech job and shove it

Found serendipitously via rc3.org, this piece on the "job market" resonates with other thoughts written only moments before. Synchronicity ! I've written about this before, but perhaps too obliquely, so it's definitely time to explore the topic once more.

One salient fact in the Salon piece, which matches my own experience quite well, is that there are almost as many job listings as there was before - but nobody seems to be really hiring, as in, "we have a real need to expand our capacity for work, and can afford to spend money to acquire that capacity".

The author, Farhad Manjoo, points out several clues which suggest that something odd is going on. Job postings that require combinations of skill, expertise, length of experience, and low salary requirements which are simply unrealistic, or at least (I suppose some people take on some of these jobs in desperation) quite unreasonable. Job postings which, on top of that, advertise for candidates who will be "excited" and "motivated" by these non-opportunities. As fuckthatjob.com aptly puts it, the attitude is "fuck you, you need a job".

Myself, I've seen a little bit of that. There are the countless recruiters who don't even do you the courtesy of a reply to your application. Worse, there are the job listings bearing the mention, "If you don't receive a response from us within three weeks, please assume that we have turned down your application." I'm tempted to put up a site somewhere that says, "If you don't receive an application from me within three years, please assume I've come to the conclusion that you're a bunch of a weasels" - and I think fuckthatjob.com is just how one might express that temptation.

Personal anger aside, my feeling is that these various weird behaviours point to a somewhat disturbing conclusion. The job market isn't really a "market", since its effective aim is not to negotiate the exchange of one commodity (work) for another (wages).

It is perhaps better seen in the light of systems thinking. The job "market" is a system, and an organized one at that, but also one which has superseded its original purpose; it has taken on unexpected and unintended dynamics which actually work in the opposite direction to what is sought. As a market, what it should be achieving is the efficient matching of skill to task, and of offer to demand.

Rather, the job "market" is now the locus of much wasted effort and money, a lot of which apparently only goes toward venting feelings of blame, antagonism, and power complexes on the part of employers towards employees. This will inevitably create further oscillation, further instability, further unintended systemic effects, on the parts of employees.

Consider the "quit and stay" syndrome. I left my most recent salaried position voluntarily, because I felt my skills were entirely wasted. Some of my colleages and friends have told me they feel the same about their current job, but leaving simply isn't an option to them "because of the state of the economy". They are "people who still come to work, but don't bring their heart with them anymore".

This is a tragedy in itself, but try to picture the systemic consequences. As soon as people start to perceive improvements in the economy, and thus in the job market, they will finally feel safer about "quitting and leaving". Job hopping might resume on a large scale, with the result that once more companies will be faced with staffing crises. This could cause, as a short-term effect, a reversal of the job "market" in favor of workers, soaring salaries and so on. But simultaneously there would be an effect only felt in the longer term, of decreased productivity in the companies where this was widespread. And if this led again to an economic downturn...

Now, this picture of the system is probably too simplistic, too fanciful. But I observe that, more and more, we live in a world of oscillations, of instability. (Not a profound observation these days, I'll readily admit.) As Dietrich Dörner explains in The Logic of Failure, humans' native ability to deal with complex systems appears to fall short of what would be required in this modern world. We must practice and learn systems thinking, collectively, if we are to deal with this instability. Our survival depends on it.

Just saying "wait for the economy (or the job market) to improve" won't cut it. We must expose what is wrong with the economy (or the job market), as a system, and work to fix it.

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

17 March 03 - 09:59Promises and Predictions

Frank Patrick: Provocative proposition

"Agile methodologies are about task/work management, not project management." [...] "The agilistas seem to be saying 'don't bother with promises or predictions; just let us get to work on delivering value bit by bit.'"

I think there's value in that observation, if we turn it on its head. (To do otherwise is, perhaps, to run the risk of reenacting a tedious argument that pops up over and over, and which I find less than useful.)

To the extent that a project, Agile or not, says "Don't bother with promises or predictions", it is missing the whole point of "project management" (for the moment not examining the phrase too closely). The project is also, most often, headed for trouble. It is perhaps the case that Agile or XP projects are more prone to this failure mode than projects managed under "rigorous" methods - though I've certainly heard of many projects which started with rigorous planning and then devolved into "just let us ship bit by bit".

Part of the problem, perhaps, is that often we are lumping "promises and predictions" together, and Frank's phrase is of interest to me precisely because it calls attention to the fact that they are different aspects of project planning.

We cannot predict in detail the future states of a complex system (if we could, it wouldn't be a "complex system" in the sense that attracts scientific attention). So at least in some of the ways we understand the term, "prediction" is of limited value on software projects. Frank suggests a strong argument in this direction by pointing out that the things we most often try to predict are not directly relevant to what is at stake:

"Software tasks, appropriately managed via agile processes and organizations, almost never deliver the actual end result of the effort. They deliver supportive components of business processes or products that require coordination with non-software components."

Most of the time, these non-software components are human components, in fact, and decidedly nonlinear and difficult to "predict" in the sense of anticipating future states in any detail.

The "promise" aspect on the other hand holds much more, well, promise.

- Blogversations - one comment / No trackbacks - § ¶

17 March 03 - 09:02Exploring value

Brian Marick argues that you'd be less likely to spot the usability issue I reported if you were using only automated testing in the style of Test-Driven Development.

To Brian, this supports the case for Exploratory Testing. By which he means, contra the Extreme Programming doctrine of "No manual testing" and contra Danil Suits who argues that it's a UI design issue, that someone who is "manually" testing the product as a user would, and with somewhat the same mindset as a user, would be in a better position to spot the problem.

I think Brian makes a good case for Exploratory Testing, but the example test script he gives undermines his own point re. automation. I'll try to explain why in a moment. To me this is suggestive of complementarity rather than contradiction.

I view the Tester's role as identifying, anticipating and exploring risks to quality; i.e. looking for anything which might make the software less valuable to one of the people who have something (money, time or whatever) invested in it. The more the Tester understands what makes the product valuable, the better equipped she is to look for related risks. (I'm using Tester here to refer to a role, not necessarily a person solely dedicated to that role. On XP teams, programmers take on the Tester role some of the time.)

Obviously, a Tester who is familiar with how the product feels "from the outside", from the user's point of view, will gain a lot of insight into such risks.

It seems to me that articulating the details of the feature to the degree of precision implied by Brian's example automated test script would also give the Tester much insight into why and how the feature is valuable. Particularly if the test script is the result of a conversation that starts with asking the user or customer, "How would you know that the overdue checkin feature works correctly".

- Blogversations - No comments / No trackbacks - § ¶

16 March 03 - 09:26Journals

Confessions of an Intermittent Journaler

In Esther Derby's blog, which I shall be watching (and does not appear to be set up with "permalinks" yet, so I can't pick out this particular entry other than by its title). [P.S. Thanks to Alan - see comments - this entry now links to the appropriate place in Esther's blog.]

"I some times suggest journaling as a useful tool for people who want to become more effective leaders. [...] But the truth is, I haven't used a journal consistently, at least not up until now."

Esther's is a wonderfully candid confession. (Clearly, one part of what makes keeping a journal so effective is this "open kimono" stance. Honestly recording how you fall short of your own ideals. Then you can work on improving yourself, or discarding the ideals as unrealistic. Neither does it matter much whether the journal is public or private: for me, once you've admitted something about yourself, you might as well admit it to others.)

There are different ways and different reasons to use a journal. I liked very much what Peter had to say about blogging, even though my own motivations are completely different. Nor is the "blog" format itself anything but a convenient tool; one very deep, very interesting public journal I've read recently resides on a Wiki.

It was back in 1999, maybe 2000, that I got into the habit of keeping an "engineering log" at work, on orange notepads. This was simply for timekeeping purposes at first; I recorded a list of the tasks I'd worked on each day and how much of my time they had taken up, to a granularity of a few hours. Then I added to that a very concise recording of some significant events, technical or not.

This proved to be occasionally helpful (for instance when I was asked to account for how I'd spent my work time by a manager) and very undemanding in terms of effort, so I kept it up.

I only kept a "true" journal once before this blog, the first few months in a job back in 2001. I had started out very enthusiastic about that position and became nearly depressed with it in a very short span of time. The journal recorded this. It helped in pinning down some objective causes for my feelings. Strangely enough, though, I stopped keeping the journal after a few months - after which my mood improved, and I was finally able to muster some cheerfulness on the job. I managed to stay on and do my best for the business until it collapsed financially - in my analysis due to reasons related to what made it such a depressing corporate culture to work in.

I started this blog because I thought it would be good practice in writing about the topics that interest me. It's not really an end in itself. It's where I try out some ideas that I want to develop further at some point in the future.

The name reflects this: it's meant to read "Incipient(thoughts)" - the dot and two O's leading up to the curly braces are ASCII art for a "thought bubble". It's happy coincidence that the two O's reflect my interest in OO programming.

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

14 March 03 - 16:38Software Factories

The Software Factory vs The Software Factory

Menlo, who are known as an Agile shop, don't recoil from using the "Factory" metaphor for software work. But as the first link suggests, the image has strong connotations of a Taylorist mindset.

The Software Factory appears to be a fairly common fantasy. One former employee of mine wanted one, too. They are now defunct. No causal relationship implied.

Today I came up with the following allegory. It doesn't teach anything, it asks a question.

A manager once worked in a factory where a dozen workers cranked out espresso machines on an assembly line.

This was a nice factory, with a spacious and well lit work space, a small yard outside for the two five-minute breaks allowed each day, and a conveyor belt to the warehouse, from which, all day long, espresso machine after espresso machine was delivered for packing into neat cardboard boxes, stacking and shipping.

The manager's favorite place was at the end of the conveyor belt, counting espresso machines. One, two, three, four - five espresso machines; and one minute had gone by, the manager's watch told him. Five espresso machines per minute, and the manager was happy. His workers were nicely productive.

It had been a while since the manager had even peeked into the work room, and one day, sitting at the end of the conveyor belt, counting espresso machines, the manager's grin widened. Five, six, seven espresso machines per minute ! Nor was this a fluke - it kept up all day long instead of abating as the manager expected.

Intrigued, the manager went into the work room to observe the next day. There he found that the workers had rearranged all the furniture and work stations, and instituted a system of work he didn't understand. Moreoever, throughout the day, two workers at any one time were in the yard, chatting and laughing and playing ball. They frequently switched places with the workers inside. Everyone seemed very happy.

Now the question. What do you suppose the manager did ? Please send in your comments.

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

13 March 03 - 11:51Projects

What is a Project ?

I don't know if it's something wrong with me, but I appear to have trouble with words that other people seem perfectly happy to use without a second thought. Among these are "team" and "project". Here's how a page I came across defines a project:

'Routine work covers the normal things you do as an ongoing part of your job. [...] On the other hand, projects are not routine. The biggest difference is that projects, by their definition, have a defined start and end-date. [...] However, other characteristics of a project include a defined scope, finite budget, specific end result (or deliverables) and assigned resources. Another characteristic of a project is that the work is unique."

This fits the way we use "project" in software work, but only in the way an incompetently tailored suit might fit.

Defined start date ? Well, except for the "fuzzy front end", that zone before a project where people are negotiating for the go-ahead, funding, contractual arrangements, etc. Defined end date ? Which date is that - the ship date, which is often missed by miles ? Or is it the date when the stream of "bug reports" finally slows down to a trickle ? The date when the system is finally put into production ?

There is also an interesting tension between what seems to be an Agile principle, that "projects" must be sustainable, or the XP notion that maintenance and development are indistinguishable; and the above start-stop definition of "project". And yet, "project" is used with perfect confidence in conversations throughout these communities.

When I think about the "project" distinction, one thought that comes up is related to emotional aspects rather than intellectual ones. What "project" distinguishes is related, in my view, to the difference between the emotion we call Hope and a stronger, more constructive stance which was wonderfully expressed by Alan Kay: "The best way to predict the future is to invent it."

To me, "project" in the sense I want to use it, e.g. for software projects, is all about an invented future. A prediction we make come true.

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

12 March 03 - 13:41Testing

Brian Marick, Brett Pettichord

Brian and Brett are authorities on testing. They are also brave people who, under grave danger of learning, stepped out of their comfort zones to try out Test-Driven Development.

I have testing much on my mind at the moment, not least because I've been talking with a potential employer about a position in QA - for an Extreme Programming team. QA would be a first for me.

My wife had the following anecdote yesterday.

She was down at the library - she's a teacher and she borrows a lot of "young readers" books. Today she had over thirty books in her bag.

She was there to return the books. The library had been closed for redecoration and repairs, for the past month.

The lady behind the counter had a grim expression on. My wife sound found out why. There is a system of penalties for books which are returned late. Now, books are normally returned within three weeks, so my wife's books were all, technically, late. But of course she couldn't have returned them before due, since the library was closed. And so naturally, there wasn't a problem with any "penalty".

Well, there wouldn't have been if someone had thought to inform the library's software system. It wasn't aware of that, and insisted on computing and notifying penalties for any books returned late.

The system had been programmed to do that by flashing a "penalty" screen after scanning each book's bar code.

Imagine that. Thirty iterations of : scan in the book - bleep : "This book is late" - hit OK to return to normal processing and move on to the next book - lather, rinse, repeat.

These bleeps get under anyone's skin. By the thirtieth-or-so book, the lady behind the counter had, understandably, had it with my wife, who by far was not the first person to come in and cause a series of nerve-ripping bleeps. Scanning in books for borrowing was out of the question. It was probably all she could do not to run screaming from the place, no longer able to face the next series of bleeps. Next please.

It's just another software horror story, I guess. I'm trying to think of this one from the point of view of someone seeing the software "from the outside", from a tester's point of view. As someone whose main role is to identify the risks to the product's quality. Getting under people's skins all day long, is certainly a quality issue. No matter that it was due to an event that, admittedly, had probably never been covered by the spec. Could a tester have seen this one coming ?

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

11 March 03 - 14:20Appreciations

Tony Bowden, quoting Jerry Weinberg, quoting Rabindranath Tagore:

"Praise shames me, because I secretly crave it."

The phrase strikes a chord with me.

To some extent, a lot of what I'm interested in these days is by way of applying the precept, "It's easier to act your way into thinking differently than to think your way into acting differently."

I don't give praise easily enough. I know for a fact that this has been a problem on past projects. One one occasion I found it necessary to give criticism of something a teammate did, and he felt that I was constantly berating him. Well, that was true enough as it went - the ratio of criticism to appreciation was overwhelming.

"Temperature Readings", as described here or here for software projects, are a very nice way of separating the various transactions that go on in projects - complaints, questions, new information - and injecting two crucial elements back into the set : appreciations and "blue sky" thinking (hopes and wishes).

So far I haven't had occasion to use TRs on software projects, but (needing the practice, and wanting to act my way into better thinking) I've introduced them in my family.

The kids love them - for, as I found out, an unexpected and interesting reason. They have no inhibitions with respect to appreciations. But the process gives them the explicit opportunity to voice complaints of their own, which is something very much not built into our expectations of how kids "should" behave.

- The Universe And Everything - one comment / No trackbacks - § ¶

10 March 03 - 18:02Mockery

Scott Stirling, re Mock Objects:

"But if your code is systematically untestable, I think you need to start looking at your code and think about why it is so. Not in terms of how you could make more testable, because I think that's the wrong question. The question should be, why is it untestable? And am I missing some opportunity to improve the code, regardless of whether it was going to be tested."

I like this. I've only ever used mock objects to help test code that was too complicated to start with.

I suspect that there's a more general rule at work here; along the lines of : if X is a band-aid remedy to some problem, look for what causes the problem to arise in the first place and how it can be actually solved; don't get trapped in "nifty new ways to do X" thinking.

I also suspect that's one way "band-aid" solutions become entrenched, and then someone coming up with a real solution to the underlying problem gets to be seen as offering "disruptive technology".

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

08 March 03 - 21:53But headed

How to be an expert listener

"A superb place to begin your new awareness of the need for greater listening is at home. It is amazing, and perplexing, to me to note that at work, I can be a relatively good listener. Then I go home to the person who means most to me in the world, and it all goes out the window."

Please take particular notice of the section at the end concerning the word "but" : at the moment my favorite example of a small, innocuous-looking word with a huge potential for abuse in conversations, especially work conversations.

I've picked up this tidbit from NLP circles. (The ones where 'N' stands for Neuro, not Natural.) I'm wondering if there is, somewhere, a theoretical framework which accounts for such effects in language.

- Private Life Of The Brain - No comments / No trackbacks - § ¶

08 March 03 - 19:46Blogging by the numbers

ISSN for Weblogs (Joe Clark: fawny.org)

For some reason I find this idea disturbing. But even more disturbing to me is the possible degeneration of the present periodical into meta-blogging, which must rank as the lowest possible form of writing; accordingly, I now desist.

- Blogversations - No comments / No trackbacks - § ¶

07 March 03 - 10:16Faff, force or flow

Mark Forster

"We are told to produce ten year goals, then three year goals, then one year goals, then six month goals, then monthly goals, then weekly goals, then daily goals. Just writing that last sentence has made me feel exhausted!"

I like what Forster, who I discovered thanks to Ron Jeffries, has to say about time management : you don't make time, you don't find time; you have, like everybody else in the world, precisely 24h in every day, and how you use each of these moments is up to you.

The problem is never that we don't have enough time. It is always that we have too much to do, and the answer is always to do less : to only do the things that matter.

Like all fundamental and blindingly obvious "solutions" to life's problems, though, this one is but the starting point of a long and often painful learning process.

A while ago I decided on the three things that mattered to me : building a loving family; making my work in software meaningful; adding to the world through writing.

Still, I can't tell for sure whether my life is in faff, force or flow mode right now. It doesn't feel like any of these three. What are the other common modes ?

- The Universe And Everything - one comment / No trackbacks - § ¶

07 March 03 - 00:35Resentment

Resentment and Acceptance

"When we coach people or otherwise work in organisations, resentment appears as one of the most prevalent moods that we encounter."

Resentment has been the downfall of several businesses I've known or where I worked.

Its effects are familiar. Resentment first erodes understanding. ("Did she really mean what she just said, or was she making fun of me ?") Then it saps trust; and ultimately it destroys the ability of people to work together effectively toward any shared goals.

"If you accept a commitment from a friend that they will do something for you that is very important to you and they do not follow through, there is a space for resentment to evolve."

The article provides "grounding" steps to help in cutting apart feelings of resentment into component parts. This act of dissection exposes the relevance or irrelevance of these feelings to the purposes we seek.

In project teams, our purpose is normally to build a future, of which we hold a shared vision. Thus the last step is to "declare the past complete" and grow out of the mood of resentment.

- Private Life Of The Brain - No comments / No trackbacks - § ¶

06 March 03 - 00:46Measuring Value

Howard Baetjer

Howard Baetjer has an article, "Towards Measuring Software Value", which at a first skim seems to answer some of the questions I was pondering recently. (Linking to the home page rather than directly to the article because the latter is in Word format.)

I'm also reading his book, Software As Capital, at the same time. Should I read the book first ? The article first ? Embarrassment of riches. I think I'll stay with the book. I've just started on it and am struck by how much it confirms my own thinking re. software development as a process of extracting and encoding tacit knowledge.

Thanks to Christophe Thibaut for the article pointer. And for lending me the book.

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

06 March 03 - 00:38Berkeley trouble

TROUBLESHOOTING

It's what they call it in the Movable Type documentation.

It's something I hate to do; not least because I'm fairly good at it, and rarely give up until I've found a solution.

It's what I've spent the previous three hours doing instead of blogging a short entry about Howard Baetjer and going to bed.

It's what I get for not wanting to install MySQL on my server and relying instead on MT's support for Berkeley DB. What happened next, apparently, is that my ISP transparently upgraded my server from an obsolete version of Berkeley DB, 1.85, to a newer one. But in the process they forgot to warn me, and to keep around the utility that would have enabled me to migrate my db files to the new version.

Thank goodness I happen to have a shell account elsewhere with a functional migration utility. Thank goodness it didn't take me all night to figure out what was happening, with the bland error message "Invalid Login" on MT's main menu as my only clue.

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

04 March 03 - 13:54On reflection

WISDOM - Writing as a Reflective Practitioner

An interesting collection of quotes and thoughts on reflection.

- Private Life Of The Brain - No comments / No trackbacks - § ¶

03 March 03 - 15:21Value and cost

How do businesses measure the value of their software projects ?

Costs are (or so it appears) well in hand. N developers, times the average burdened salary cost of a developer, times the number of calendar months for the project. Straightforward and easy.

Things are less simple with value. Why are we building this software ? A software vendor might answer "to sell into new markets". A business executive might say, "to streamline operations". How are such benefits measured ? These will be questions with "fuzzier", more complex answers.

Costs are a lot easier to figure out than benefits, so project stakeholders focus primarily, and sometimes exclusively, on costs. But a project succeeds if its (overall) benefits exceed its (overall) costs.

I've seen what happens when a project is started without a clear idea of the benefits it is supposed to bring about, and how to observe, if not quantify, these benefits.

Regardless of what process or method is being used, the project flounders as soon as its perceived costs start to exceed its benefits as intuitively assessed by the more powerful stakeholders (on either side of the client-contractor divide, if one exists), and these stakeholders "turn sour" on the project.

I think that's actually a normal, healthy reaction - why would anyone continue to support a project that is costing a lot and not justifying its upkeep ? The problem is that the "cost" side is pinned to a quantity - time - that has a solid, concrete feel and can be easily assessed, while the "value" side is floating, unattached, free to wander. Something as trivial as a change of mood of a major stakeholder will send it hurtling well below the "cost" line.

To stand a chance of succeeding, a project must "pin" its value to things which feel concrete, definite and observable, and can be quantified with roughly the same precision as expenditures.

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

03 March 03 - 13:52More blogs

A pair (natch) of pragmatic programmers : Andy Hunt and Dave Thomas.

No Trackback feature on their (otherwise nifty) RubLog, which is a shame. I like blogversations.

- default - one comment / No trackbacks - § ¶