I could do with some co-location. These days, much of the interesting stuff is happening in small specialised events that are scattered around the calendar and around the world. I, my family, and my body clock (and the troposphere) can’t hack it any more.
I’ve been looking ahead at the calendar and there are just too many small interesting events that I’d really like to get to: Google LTAC, Simple Design and Testing, several European XpDays and AgileOpen, CITCON, Consultant Camps, various “Gatherings”—plus the more established events. And, if I go to all these events, I spend all my time rattling around similar communities and don’t get to see anything radically new (to me). It might be that the full-time road warriors can just take it in their stride, but I’m out of shape.
If someone (else) could arrange to bunch just a couple of these events together, somewhere near a hub, not during school holidays, I’d be so grateful.
In a project organised as a set of nested feedback loops, development is incremental and iterative.
Incremental Development builds a system feature by feature, not module by module. Each feature is implemented as an end-to-end “slice” through all the modules of the system. The system is always integrated and ready for deployment.
Iterative Development progressively refines the implementation of features in response to feedback until they are good enough for purpose.
Yesterday we realised that there are two other categories of development:
Decremental development is where you improve the system by removing code; most systems could do with more of this.
Detrimental development is where the code you’ve just written has made the system worse.
Actually, we’ve found a couple of references for Decremental Development, one from Kevlin Henney, and a whole research proposal from Peter Sommerlad.
Actually, Nat might have thought of Detrimental Development first.
Anyway, it’s all still true and those of us who are “young men in a hurry” 1 trying to change things need to keep in mind the facts of organisational life. Here’s a sample:
Since the stone-axe fell into disuse at the close of the neolithic age, two other arguments of universal application have been added to the rhetorical armoury by the ingenuity of mankind. They are closely akin; and, like the stone-axe, they are addressed to the Political Motive. They are called the Wedge and the Dangerous Precedent. Though they are very familiar, the principles, or rules of inaction, involved in them are seldom stated in full. They are as follows.
The Principle of the Wedge is that you should not act justly now for fear of raising expectations that you may act still more justly in the future — expectations which you are afraid you will not have the courage to satisfy. A little reflection will make it evident that the Wedge argument implies the admission that the persons who use it cannot prove that the action is not just. If they could, that would be the sole and sufficient reason for not doing it, and this argument would be superfluous.
The Principle of the Dangerous Precedent is that you should not now do an admittedly right action for fear you, or your equally timid successors, should not have the courage to do right in some future case, which, ex hypothesi, is essentially different, but superficially resembles the present one. Every public action which is not customary, either is wrong, or, if it is right, is a dangerous precedent. It follows that nothing should ever be done for the first time.
Conford was one of the generations of academics who somehow managed to convert Cambridge from a combined training school for Anglican clerics and finishing school for the Gentry into something like a modern Victorian university. It might be that the university’s Byzantine organisation is what gives it the flexibility to survive. Most of rest of us, however, don’t belong to organisations that can wait 100 years to catch up with the opposition, so we’d better get a move on.
1) “Young men in a hurry” come in all ages and genders.
Whilst writing up an extended example of TDD, I was trying to be as incremental as possible, adding tiny little slices of behaviour all the way through the system: replace one component, get that working; show a connection established, get that working; show one field on the UI, get that working. I took the trouble to structure the changes so that the application was working nearly all the time, rather than having to rip it apart.
Before I learned how to make progress is such fine slices, I would have cracked open the whole codebase and made the changes in one sustained effort. That would have meant that I couldn’t stop until I finished, I couldn’t check in without branching, and that merging with rest of the team would be unpleasant. Lots of coders talk about this in terms of “open-heart surgery”.
So maybe keyhole surgery is a better ambition as a metaphor. All the invasive work is focussed on the part that actually matters, rather than having to open up a route to get there. It takes a little more effort, but it’s less damaging to the patients who recover much more quickly, so the procedure as a whole is safer and cheaper.
Jerry Weinberg has a post, where he writes about how “surgery” may a better term for what many software teams do than “maintenance”. It gives a better sense of the risks involved and why quick solutions implemented by juniors may not be the best approach.
Medical joke from when I shared a house with a medic. “How can you spot the laparoscopists at the pub?”, “They drink their beer through a straw.”
Robert X. Cringley has another entertaining rant about whatever turned up this week. Two quotations:
First, while ranting about the IT research consultancies.
There are themes at Gartner and its competitors — ideas that are presented on an almost seasonal basis like adding fins to change a 1956 Chrysler New Yorker into a 1957 Chrysler New Yorker. Two such themes that are popular with such consultants right now are offshoring/outsourcing and getting rid of legacy applications to gain agility, whatever that is.
Outsourcing, while a very popular recommendation to improve IT, is treating the symptom and not the problem. The problem is IT applications require lots of ongoing maintenance and that costs labor, meaning REAL MONEY. Rather than make applications more reliable and reduce problems, IT managers seem to prefer shopping for cheaper labor. The problems are still there. It is cheaper to fix them with offshoring and outsourcing, true, but it often takes longer. If the end users — the people who actually make MONEY for the company (IT doesn’t, Lord knows) — are unable to work from time to time, this is okay because IT is spending less money.
Second, on the acquisition of EDS by HP
I wonder what would happen to an outfit like HP Services if the company just decided to forget about acquisitions and simply invest $12+ billion in their current operation? Heck, half the people working right now in HP Services probably worked at some point in their careers for EDS (or IBM). What DNA is HP acquiring here that they don’t have already?
In his post on Creation under Constraints he uses a post from Andrew Binstock to write about the benefits of discipline on creativity. After all, is there anything more constrained than the form of a Rock’n’Roll song? Bartok had a thing about using the Golden Ratio to structure his work. Even in my misspent youth playing free jazz, the good musicians had an identifiable voice that implied form and structure.
Getting back to the point (there is one? ed.), the phrase You Ain’t Gonna Need It (YAGNI) often seems to be applied at the micro level by using primitive types: I’ll just use a String for this address, I can figure out whether I need a type later. Except that, later there are Strings all over the code, only some of which should be Addresses and, by the way, it turns out that I’ve assigned some company names (also String) to address fields by mistake.
String is about implementation, it’s not expressive in the domain of the code. And I’d double that claim for anything that involves templated collections, when there are three or more levels of nested angle brackets it’s time to turn back.
An alternative view, is to say: I need an Address, I’ll declare an empty type and add features as I discover the need. I don’t expect to need a getBytes() method on Address, but I might well need to ask it for its post code.
Over time, I’ve become more and more convinced of the value of declaring types for everything. I don’t observe this practice as much as I think I should, probably for the same reason I have too many fillings.
Incidentally, for a fine example of working under constraints, the Abelson and Sussman videos go for hours before they discover a need for mutable values.
[…] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”
Keith has discussed this point nicely. Personally, in a scarily long time in software (which including tourism at some of the best research labs in the world), I know of a handful of people who can think very hard and then type in a working program of more than 3 lines.
In the meantime, I’m curiously chuffed that the concept of mocking appears to have entered the vocabulary of someone so far away.