Geir Hedemarks blog

Neural networks

I just read an article by uncle Bob, and I am left with a feeling that I have been around this loop before. Let me clarify.

Kent Beck’s TDD book espouses writing tests that test the actual cases you want to work. You then write just enough code to make the test run – YAGNI, right?

Then you write another test, and add some more code to make that run. Rinse and repeat.

I have seen this before. I have a background from electrical engineering, and this is the straightforward way of teaching a trivial neural network how to connect itself. The results may be totally inexplicable. One of the first examples was a team that tried to get an FPGA to implement a full-adder by iterative improvements.

They ended up with a chip that had loops in there, not obviously connected to anything else. If these loops were removed, the circuit stopped working. The bits that were connected to something did not look like a regular design, created by an engineer.

Similar studies have been done using analog electronics. The University of Oslo successfully synthesized an XOR gate using subthreshold logic in the early nineties.

In other words, we have been here before. We have ten years of knowledge beyond the simple approaches described in the early nineties. This is why I had a feeling of having been around this bend of road before.

Learning how to ride

I think TDD in its simplest form, which can be found in Kent Becks book, is a very good way of learning how to use TDD. The practice has been reduced to a simple set of rules which can be followed by anyone, and which will produce results which yield a working system, given enough time. It is a bit like learning to ride a bicycle. Anyone can, given enough invested time, learn how to do it, and the practice has been designed to give small and frequent improvements.

This does not mean that everyone must continue to use the same approach when they have learned to ride. I am sure the riders in the Tour de France have a totally different approach to riding a bicycle – an approach which gives them the ability to do stuff that seems inhuman to lesser beings. In order to do this, they are doing all kinds of weird stuff, like going on 200km long rides, getting hideously expensive bikes, and – sadly – abusing illegal substances.

I think TDD is the same way. What makes sense for a beginner does not necessarily make sense for experienced practitioners. And still I see people discuss how the One Right Way of doing TDD should be. I don’t think there is one.

Emergent evolution and productivity

There is a software developer somewhere writing the tests that drives by-the-book TDD. The tests, and the incremental improvements described in TDD, will give a system that evolves over time. A known problem with the kinds of evolution possible with these kinds of rules is that they seek out a stable solution – not the best stable solution, but a stable solution. For a system as a whole, this is not an issue. It is tough on the individual organism.

The problem with applying neural evolution to software development is that software development is both slow, and linear. By linear, I mean that a team usually only evolves one version of a system. Several companies may develop a handful of versions, but still a statistically insignificant portion of the possible number of solutions. It is also not nice being one of the organisms (companies) with a substandard solution – you are going to be in a world of hurt if a developer comes up with a different, and better, solution.

Hopefully, the developer knows a bit more about what is going to happen in the future than what the tests show. I feel he should also be part of the equation, possibly because I see myself as a software developer. I am hoping here that more knowledge put into the design process will give a better solution.

Sadly, there are some managerial thoughts going around our profession which toy with the idea that developers are replaceable cogs. If you can find a cheaper developer, go for it. The solution is going to become cheaper, right?

The problem with that is that some studies point to there being a factor ten difference in developer productivity. How interesting is it to save 50% of the money if the new developer only produces 10% of the value? You are going to need four more developers to keep the speed up, which is going to give you 2.5 times the effective cost.

Developer productivity should obviously be part of the equation. I feel quite strongly that the ten-fold increase in productivity that has been reported may have something to do with the knowledge sitting in the heads of developers, since there is a very hard limit to how fast it is possible to type. Therefore, applying strict YAGNI and pure-bred TDD may not make sense – if you have developers who give above average return for your money. And you do, right? Otherwise, why did you hire them?

Slack

How can you tell if your developers are of the few who should be given some slack?

First of all, this has absolutely nothing to do with age. I have people on my team with two years of experience who outperform people I know with ten years of experience. Getting hold of old developers will probably yield a bunch of administrators. Our profession seems to promote the best developers to managerial positions, with another sizeable chunk taking managerial positions by themselves. Alistair Cockburn said he does a “tech reset” every five years to keep his hand in. I am very glad one of the most prominent figures in the industry said that. All too few senior (as in grey hair, not skill) developers actually do this.

I have only found one way of being absolutely sure of who to cut some slack, and that is to actually do it. Let them decide how to go about things. Set reasonable expectations, and follow up after delivery on what happened. Make sure that you are talking to the person who has actually done the work – some developers are political animals, and will happily take credit for work done by others.

After six months or so, one or two of the developers in a team usually stand out as better-performing. You want more of the mojo these guys or girls have. These guys should be given time – not time off, but given time – to do what they do best, which is analyze, come up with improvements, understand the business and help the other developers become better developers.

The downside of this is what the rest of your developers will be getting up to. One or two of the rest of your team will have spent the slack you have cut them to implement their own quicksort libraries instead of providing business value, have actually been slacking around, or have created code that contains critical bugs. There is no way of finding the stars of the team without also finding these people.

I prefer actually finding these people rather than having them live as submarines in the team, only visible through their shoddy work bubbling up through the waters when a deadline looms. Knowledge is the first step towards actually doing something about the situation.

For a far more eloquent explanation of why developers need to have a bit of slack, I suggest “Slack” by Tom DeMarco. I actually had to replace this book a couple of years ago because one of my bosses hung onto it.

(Inspired by Alistair Cockburns presentation on “the death of agile”, his keynote at Agile 2009, available at http://www.infoq.com/presentations/cockburn-bury-not-praise-agile )

P.M.’s, agilists, programmers, lend me your ears;

I come to bury Agile, not to praise it.

The evil that methods do lives after them; the good is oft interred with their bones;

The noble Cockburn hath told you Agile was dated: If it were so, it was a grievous fault and grievously has Agile answered it.

Here come I to speak in Agile’s funeral. It was my friend, faithful and just to me — but Cockburn says Agile was dated and Cockburn is a knowledgeable man.

It hath brought many teams speed, whose savings did fill their coffers. Did this in Agile seem dated?

When teams were delayed, Agile gave control — seems made of sterner stuff. Yet Cockburn says it was dated, and Cockburn is a competent man.

I speak not to disprove what Cockburn spoke,

But here I am to speak what I do know. You all did love Agile once, not without cause.

What cause witholds you then, to mourn for it now?

Oh judgment! Thou art fled to brutish beasts and men have lost their reason.

Bear with me. My heart is in the coffin here with Agile and I must pause till it come back to me.

But yesterday the word of Agile might have stood against the world; now it lies there.

And none so poor to do it reverence.

Oh masters, if I were disposed to stir your hearts and minds to mutiny and rage, I should do Cockburn wrong, who, you all know, is a knowledgeable man.

I will not do him wrong; I rather choose to wrong the dead, to wrong myself and you, than I will wrong such a competent man.

Here is an opinion, in the Agile tradition — I thought it up myself, ’tis its legacy: Let but the people hear this legacy, which, pardon me, I do not mean to give, and they would go and kiss dead Agile’s wounds and dip their napkins in its sacred blood, yea, beg a hair from it for memory, and, dying, mention it within their wills, bequeathing it as a rich legacy unto their issue.

Have patience, gentle friends, I must not give it; it is not right you know how Agile served you. You are not wood, you are not stones, but men; and, being men, hearing this opinion of Agile, it will inflame you, it will make you mad! ‘Tis good you know not that you are its heirs, for if you should, oh, what would come of it!

Will you be patient? Will you stay awhile? I have overshot myself to tell you of it. I fear the highly competent man whose daggers have stabbed Agile, I do fear him!

Then make a ring about the corpse of Agile, and let me show you it that caused my thoughts. Shall I descend? And will you give me leave?

If you have tears, prepare to shed them now. You all do know these parts of Agile — I remember the first time I tried them out. ‘Twas on a summers evening, all alone, that day I finished a project in time.

Look — there is the standup meeting! See how the backlog has been broken! Through communication did we gain speed, and as your teams became self-managing, mark how the speedups followed it, as rushing out of doors, to be resolved if Cockburn so unkindly knocked or no.

Oh, disciples of agile, the naming of the parts was a necessary evil. The naming of parts created a bigger whole, losing us our way. Only through us did agile gain life and mortality.

For Cockburn, as you know, was an angel of agile — judge, oh you gods, how dearly he was loved. This was the most unkindest cut of all! For when even the angel took a stab, confusion, more strong than traitor’s arms, quite vanquished us, then burst our mighty hearts, and in our despair clouding our thoughts, even at the base of our professions grail, we raised poor agile to the lares, thus it fell.

Oh, what a fall was there, my compatriots! Then I and you and all of us fell down, while bloody confusion flourished over us!

Oh, now you weep, and I perceive you feel the pang of guilt — these are gracious drops. Kind souls, what weep you when you but behold our agile’s vesture removed? Look you here! Here the parts lie, for you to reuse.

Good friends, sweet friends, let me not stir you up to such a sudden flood of mutiny. They that have done this deed are honorable. What private thoughts they have, alas, I know not what made them do it. They are wise and honorable and will, no doubt, with reasons answer you.

I only speak right on; I tell you that which you yourselves do know; show you sweet agiles parts, poor dumb practices, and bid them speak for me…

Here is the worth, and under agile’s tradition. For all of us, experience to gather!

Moreover, we can change all its ways, its private arbors and well-tended practices — this is all left to you.

And to your teams forever, common knowledge, to gain wit, to constantly improve.

Here was a method. There will surely be another.

With apologies to both Alistair Cockburn and Shakespeare.

Javazone is on – one of my local java conferences. Quite a good one, too. Couldn’t make it this year, though.

Presumably, there will be people talking about the latest way of aggregating bits into a bigger whole. It doesn’t matter what you call it – portlets, SOA, mashups. It is something every developer sees the value of and wants to do.

Then we want to get someone to host our applications. This is where twinkly-eyed developers meet a bit of an impasse.

Let us say an application wants to incorporate maps from google. This service is hidden beyond the hostname maps.google.com – but there is no way of knowing what this service resolves to in way of IP-addresses. Google has several data centres, and will presumably move their services around as they build more. Hosting people tend to like hiding our bits behind firewalls. Services migrating around is not compatible with any hosting products I have seen. There is an inherent flaw in the available hosting products – they tend to require a firm coupling to any external services that are used. Right now, that is not too much of a problem since few people successfully use cloud-type technologies. If clouds take off, this will become a major headache.

In extreme cases, even resolving hostnames to IP addresses is a problem. Old silo-type systems do not necessarily require access to DNS – they are self-contained. DNS is a somewhat fragile protocol opinion, so this might not be a totally silly idea. If is a bit too easy to steal domains or to poison DNS. Still, most mashup-like technologies tend to lean heavily on DNS to provide location information.

I think an improvement to DNS would be in order. I want something

• I can control dynamically. I may want to switch traffic between locations very much faster than DNS allows. Some DNS resolver implementations do not even honor the time-to-live field.
• is secure. Man-in-the-middle attacks and DNS poisoning should be impossible. It should be very easy to switch DNS server providers, but very hard for someone to steal my domains.
• is context-sensitive. It makes absolutely no sense for someone in the US to use the same hosts as I do if someone has data centres in both Europe and the US.

Before this is sorted out, I am afraid I don’t have much hope for the kind of cloud computing I want to see. I am sure we will have lots of technologies claiming to be “cloud”, but they will still tie me to one hosting location too firmly for my liking. I have seen power outages and in extreme cases fires and flooding taking out whole locations, and these situations are never fun to get through. So far, my current project has seen two power outages, a major routing loop (hi, Sverre) and a catastrophic fire taking out our development systems. We always managed to get up and running again in less than a day due to very competent people and good backup routines, but significant loss of sleep was incurred along the way.

So – I want some really flexible solutions, thank you very much. And then I want hosting vendors to adopt these technologies. That is probably never going to happen, since this kind of technology would also open up competition between vendors in a completely new way. If you can switch away from a hosting location on very short notice because of a fire, you can probably also do it when some marketeer decides to up the price.

Still, it is a nice dream. It would make SOA, mashups or whatever this years’ buzzword is very much more achievable.

Trygve Reenskaug and Jim Coplien are at it again. They have produced an excellent article on a possible post-OO way of structuring information and behavior.

This is a problem that several people have sought to solve in the past. Aspects and Qi4j are some of the latest attempts.

I heartily recommend Trygve and Jims article. I think it describes the problem clearly, and it doesn’t hurt that they are thinking along the same lines I do, of course.

If you want to see these two guys live, they will be giving a presentation of this paper at the Roots conference. This is a shameless plug, though. One of my very able colleagues are on the organizing committee.

It is fairly well known to most developers that comments should provide value. The following snippet has almost disappeared totally from the codebases I see.

public class Foo {
//Constructor
public Foo() {
//Add one to a
a++;
}
}


The next wave of problems is probably going to be comments elsewhere. Source code repositories like subversion allow comments to be entered during a checkin.

Do you use this feature? If you use it – do your comments provide value, or do they read “checkin”?

I sin against this myself from time to time. Don’t do as I do. I have found that it is very instructive to include my thoughts on what I am attempting to accomplish when I check in. If there is a JIRA (or Bugzilla, RT, Redmine – choose your own poison. Mine is JIRA) issue, I try to remember to enter the issue number.

Then again, people write documents. Most document templates I have used over the years have had a changelog table at the beginning of the document. An example of such a table can be found in my installation guide template. I have now seen some of you use this template, which is why I am writing this post.

The changelog table is there to help the operations team that install the software get a grip on which parts of the document have been updated between versions. If this table does not provide value, the installation document will not be read after the third release, and the installation will break. There will probably be one or more issues registered (“it doesn’t work”, which is an error report that has the same problem I am writing about here), people will get frustrated, and your project will grind to a halt.

Don’t enter comments along the lines of “updated for version 17″ in the description column of this table. Enter something useful. If you rewrote a section, say why and which section(s) was involved. If you have added a configuration parameter, say so, and give a reference to where in the document the parameter is described.

This allows installations to be performed incrementally, which in turn will save money, which in its turn will leave resources for more useful stuff to happen.

Comments can provide lots of value. Make sure you know how to use them wisely.