Geir Hedemarks blog

I have a guy from Sweden on my team. He is an accomplished developer, and also a very reflected guy.

A couple of weeks ago, we had a discussion about cultural differences. He came up with an insight I have been thinking about for a while: norwegian developers are harder to lead than swedes. As I understood him, we tend to rebel against being constrained.

The kind of constraints I am talking about is the good kind. The kind where the product owner tells you that he needs some feature before some date for it to make sense. Can you do it? No? Is there something you can do to make it happen? I am not talking about the other stuff.

And here the rebellion lies. Norwegian developers tend to question the need to have a given feature out by some date. We question the need to save money – a couple of hundred thousand of whatever the local monetary unit happens to be can’t make a difference, can it? We spend so much already? We tend to question the need to cut corners instead of describing the horrific consequences which enable someone else to make the decision.

Mike Cohn has just written about removing team members. In his post, he describes something he calls the CDE model. The CDE model describes a container that is placed on a self-organizing team.

The container are the boundaries the team is to operate within. I view constraints on feature dates, which features to add, and cost to be the container we are placed in by the product owner. The product owner owns the budget, the resulting product, and all the problems that come of cutting corners. It isn’t really up to a developer to “adjust” this container. A good developer will tell the product owner what problems he will end up with, but the decision to actually suffer the consequences in order to achieve something else lies with the product owner.

I think this may be to do with the negative view of non-techies that is pervasive in some environments in Norway. If you have a background in economy, chances are that some techies will look down on you, using the somewhat derogatory term “blåruss” to describe your position. Yet I never saw a company succeed without some kind of economic control.

I am worried that norwegian developers are being described as what I view as container-averse. I don’t think we will get agile projects – or any other kind – to become successful products if this is actually correct. I hope this very insightful developer is wrong, or has been unlucky in his coworkers.

I have been fooling around with Scala, Lift and Spring the last couple of months.Why? I want to see if this combination of libraries and languages can make me more productive than my current preferred application stack. I also like the prospect of having to write less linear text (stuff like getters and setters) in order to accomplish something.

Underlying this is a wish to kill off the factory (and, up to a point, the singleton) pattern. When I first started using Spring a number of years ago, a new world opened in terms of maintainability of my code. Inversion of Control (IoC) was the enabler of this leap forward. I think I have only written a handful of factories since.

I am basically looking for a stack that

• has some kind of inversion of control that enables regression testing outside of a container/in an IDE without requiring deploying test structures in production, or changing code to run tests.
• has declarative transaction control, along the style of Spring’s @Transactional annotation. Many of the Scala/Lift examples I see has little or no transactional demarcation.
• has most of the infrastructure stuff I need already present – I do not want to even hear people talking about how easy it is to roll your own. I want stuff to be mainstream and recognizable. None of the companies I work for make money off of doing infrastructure like ORM. It might be symptomatic that Scala so far has two ORM frameworks (Mapper and Record), and three Actor implementations. I expect this flurry of library creation to die down after a while, though. Java wasn’t much better around 2001.
• enables me to separate my applications along vertical layers, and which helps me separate presentation and business logic. This does not mean I want nonfunctional wrapper layers.
• is efficient and bug-free.

It turns out other people is thinking along the same lines as I do. A good discussion can be found in this thread. This is a discussion between java/spring based people like me and the authors of libraries like Lift. One side wants IoC, the other says not to bother and use something like Lift’s Boot class instead. And at a superficial level, this isn’t too bad.

The boot class used by Lift looks like a stripped-down Spring XML bean definition list: “Class A needs to have an instance of class B”. I mostly don’t do these kinds of configuration items any more. I tend to declare my services using an annotation (@Component or @Service), and telling beans that use then that they need something injected (@Resource). I think this is cleaner since all the information about the wiring of my application is right there in the code, where it is easy to find for other developers.

My Spring config files deal with transactional support, databases, security, ORM – and test support. I also really, really like the pre-made test libraries that come with Spring. They make it so much easier to get people started with regression tests. None of these are available in Scala, and it seems to be somewhat less than trivial to retrofit these parts of Spring to Scala.

I haven’t decided yet, but I do know that I don’t like my production Boot class knowing about my test structures. Need to think about this for a bit.

Developers are strange. We tend to spend hours discussing which feature is the best, what language to use, which color our laptops should be.

One of the longest and most polarized discussions is wether strong or weak typing is the better. Then we go on to select a language based on our preference.

Both camps have points. Weak typing allows you a more flexible domain object tree, where you very easily can add new stuff. If you can keep control of your design, this is clearly good. Strong typing allows for more error detection in your IDE – if you use an IDE. You do, right?

I could go on and on, but the problem we tend to create through these discussions is that one tool is not best for all applications. The domain I am going to write about today is integration.

If you come from the weak typing camp, you are probably used to the idea that you can accept any object that conforms to the interface you actually need. If you need version 7 of an interface, and the producer guarantees backwards compatibility, you are probably quite happy to accept even version 10 of the interface. In cases where very good designers have been around, I have seen the client ask the producer wether it can produce data that is compatible with the version it can accept. This very seldom happens in the software world. This is mostly the domain of hardware designers. My macbook is able to detect wether an external display only has a resolution of 800×600, and adjust accordingy. This type of negotiated versioning is my personal favorite – but then again, I have a hardware background.

Other camps accept whatever they get, store it away, alert someone, and then hope someone upgrades the application before the information that is available in the new version is needed. The benefit of this is that the problems gets pushed forward in time, and does not create problems until the very last moment when the information that is unparsed is actually needed. There are benefits and drawbacks to this solution, but it has worked very well for those who are able to view their integration points as a document.

Imagine adding strong typing proponents to this mix. Strong typing means knowing exactly what your objects can look like. My macbook would only accept the 30″ apple-branded displays, making it unusable when I want to present at a conference with an unknown projector. This is where 95% of the integration platforms out there are. To me, it seems like this branch of integration platforms has grown from the language-supported method call interfaces we use internally in our applications, through CORBA, then we did the same thing again only with XML and got web services, which have now evolved into JBI, where stuff looks like documents, but are very strongly typed. These technologies seem to cause teams to make only token efforts towards governance. I have found none who are forward-compatible.

I come from a company where people have been thinking about this for some time. These people have now moved on, but the ideas are still around. One of the ideas brought forward by this bunch of people is to do away with most of the web services stack and use xpath to pick out the bits of a message you need. If elements you don’t recognize and don’t need appear in the message, the extra information is ignored. More information from these people can be found at the Cantara wiki.

So – where am I going with all this? I am a proponent of strongly-typed languages. I have seen too many projects fail because most developers lack the discipline necessary to avoid abusing a weakly typed language. That is why I prefer Scala to Ruby.

I am not a proponent of strongly typing everything, though. Strong typing is a good idea inside an application. Anything that is outside the application is going to be less under the control of the developers than whatever is inside. This is a fact. Nothing to do about it. Therefore a different approach is needed in order to avoid hideously large development/maintenance costs. This other approach is going to cost the team more, but the cost is going to be lower than trying to treat the outside world as something that can be controlled. I am not even sure I would want to do that – the implication is that the slowest team in the outside world is going to control the speed of your team, too.

This is where my gripe lies. I want to be able to selectively select how weakly an interface should be typed. When I assemble interfaces, the typing should affect how they interact. Right now, there does not seem to be a language that allows this. All languages have a one-size-fits-all approach to typing which is going to be wrong sometimes. The best compromise I have been able to find so far is the cantara or spring integration approach with the strongly-typed Java.

Perhaps in ten years…

I have been getting more and more questions from both managers and techies about scala lately. Is this the time to switch to scala. This time, I am going to address the management/architect side of the question.

“Should I switch to scala” usually is the wrong sort of question. A better question is “what can I change that will improve my situation”. Techies usually have a habit of jumping the gun when it comes to technology-related issues. We dive right into the things we know best – the technology.

A lot of organizations are troubled by this. Why does the question come up at all? What does not work out for your organization? Very often, the question is a variation on “we need to get stuff done faster, and once it has been delivered, it needs to continue working”. Fixing the things that will give the biggest improvement first is usually the way to go. So where in all this does Scala – or any other “cool” technology – come into the picture.

This is my preferred list of todos before starting to fiddle with the technology stack, provided there is a workable technology stack around:

• QA and testing. Many organizations do not have a workable regression test suite around, or have a regression test suite that gets in the way of changing the product. This will give a test workload that increases with the square of the number of features in the product. This will work out for the first couple of months, but the cost of not having a workable, automated regression test suite will quickly cause management or customer attention.
  There will still be a need to test every release. Regression tests are about ensuring that the stuff that worked in the last release is still operational. Anything that has been done in the current release, and anything that is of a visual nature, will have to be tested manually. Regression tests are there to reduce the cost of the tedious testing – the stuff that needs to be repeated every last release, and which gets bigger and more complex for every release.
• Requirements capture. Many organizations are not very good at selecting which requirements should be implemented, and in what order. I think this is a sign of office politics – someone is out to increase their dominion without regard to the health of the organization. Mental visions of big, flaming eyeballs, orcs in their thousands, and tall, forbidding, black gates are appropriate here. The organization will never have any chance at being remotely efficient before the evil dominions have been reduced to a size where the overlord has to explain why there is a need to have big, black, forbidding gates inside of the organization, until the orcs turn out to be kids with poor complexions and butter knives, and the overload has to pay for the effect his black gates have on the organization from his pre-existing budget.
  Of course, the evil overlord may be the head of IT. Nothing makes an evil overlord like an IT guy. We are too well read in the science-fiction and fantasy worlds not to have picked up a thing or two. There needs to be a balance – read the Recluce books by Modesitt for a fantasy introduction to balance, otherwise have a go at “User stories” by Mike Cohn.
• Knowledge  management. This has nothing to do with ITIL processes. This is about one part of the organization knowing what the other does. It is about developers understanding how tasks are performed by users of the system. It is about one developer being able to pick up where another left off. It is about management being willing to listen to arguments in non-managerial language.
  This is in direct conflict with being “more efficient” in the short term, and is therefore a problem with some current managerial trends which tend towards optimizing short-term profits to pump stock prices, even at the expense of long-term profits. Developers should get time out to clear up costly “technical issues”, they should work tightly with the users of the system so they understand what is needed, and so on. They are not creating new functionality while they are doing this, and will therefore be “less productive” and give less impressive results in the next financial report.
• Lifecycle management of the software is something almost no development organizations think much about. I have had people yell at me when I asked what the life expectancy of a system was projected to be. The system was rewritten from scratch two years later. Switching technologies is not an interesting question compared to throwing away all the code every two years. So – how long is the system meant to live, and what should it cost? Should it be possible to make it into a product?
• Personnel issues are a recurring problem in our profession. We had a visit from Uncle Bob a month or so ago, and he said something about not having weapons in the same room as two senior developers. Sadly, he was right – some of us are hard to work with. These issues can overshadow any benefits gained from moving to a new technology.

Any organization that does not have good control of all of these issues, or who have taken steps to get them under control, should not be thinking about adopting Scala. Fixing any of the above issues – if they apply to your organization – is going to have a much bigger impact than Scala ever will. So – make sure that introducing a new technology is a good idea.

Moving to Scala is going to require investments in new knowledge, there will be technical issues that will have a direct cost both in time and money, there may be downtime. Scala is also a very immature platform compared to Java or .NET. The benefits and risks should be carefully weighed before going for any new technology. This is my own list of pros and cons for Scala right now:

• Pro: The language is “more orthogonal” than Java. This makes for a language that may require fewer workarounds and sticky-tape solutions.
• Con: Developers have tendency to abuse new and “cool” technology in an attempt to show off. Unreadable or unmaintainable code is a problem whatever language it is written in.
• Pro: Scala can reuse existing libraries from the java world. This should improve efficiency, especially if there is existing knowledge of Scala libraries in-house.
• Con: There is very little knowledge about what bugs may be caused when using Scala with these old libraries. This, sadly, is a also developer-dependent. The organizations that are already using Scala will have solved their own teething troubles – but this does not mean your organizations will not create the same kinds of problems.
• Pro: The designers of Scala have created a language that is less verbose than Java. This is significant because Java applications tends to get unmanageable by sheer codebase size.
• Con: The development tools available for Scala are horrible. The best one while I am writing this is IntelliJ, with Eclipse in second place. I don’t like the compilation model of IntelliJ, so I am sticking to Eclipse. Netbeans is not a contender until the Oracle noise has been resolved.
• Pro: Developers want to use Scala. Hiring talent is probably going to be easier, depending on what the previous technology in use was.
• Con: Scala might not make it. What happens if Scala turns out to be a fringe language in two years? The risk of having to do another rewrite in another language should be factored into the decision to move to Scala. Personally, I believe in Scala, but there are no guarantees.

Now, don’t misunderstand me. I am going to try to find the time to write a small application in Scala during the next half year or so. I like the language. I am looking forward to getting rid of the non-functional fluff that is irritating me in Java. I just think organizations wanting to move to Scala should have a clear idea of why they are doing it, and what they will have to sort out along the way. Having a strategy or at least an explanation to the challenges posed here is a way to actually get to experience the benefits made possible by Scala.

Oh, and have a happy new year.

I am getting old, I know. Old enough that I have allowed myself to slow down a bit and actually ponder what people around me say – and how they try to get their points across. It is an experience which sometimes ends up with strange insights.

I have just been at home a couple of days celebrating christmas, and got to thinking about people in power (architects, project managers, choose your own fancy name) who have turned out to be a bit off the mark.

These are the most memorable opinions I have heard the last couple of years:

• “We don´t do it like that here”. This statement is wrong because it doesn´t actually address whatever caused a suggestion of whatever is “not done”. I am sure most developers have come across this one. It even has its own name: “Not invented here syndrome”. This is first since I come across it so often.
• “I am here to create a counterpoint to your opinions”. This statement is wrong because it doesn´t take into account who is wrong. Taking the opposite viewpoint is never a good strategy – one opinion has to be wrong.
• “We follow best practices”. The practices in question were out of date, and from the pre-EJB 1.0 time. This statement is wrong because it assumes that whoever has created the best practices have created something that is applicable to all situations. In this case, common opinion was that the pattern never was a best practice at all. This is a variation on invoking God – in this case, the deity in question was one of the original Sun blueprints.

All of these examples have thing in common. Whatever was being said was not backed by an argument based in long- or short-term gains for the project or the organization.

I know I have done this myself in the past. My resolution for the next year – to become a better professional – is to never, ever do this again.

What is your resolution for the new year?

I have had a search going the last decade or so at the biggest job posting site in Norway. I like knowing which companies are hiring, and what kind of people they are looking for.

The last year or so, I have seen more and more job postings with variations of “you need to have worked in  very expensive projects”. It usually isn’t worded exactly like this, though. The usual phrase is based on looking for  some kind of leadership role, but only if you have experience with major projects – and here major projects are measured in money. “Need to have been a <something> on projects which cost more than <some nine-digit sum in NOK>”. So far, we haven’t been able to run projects into ten digits here in Norway, and I really hope it isn’t just a question of time.

This mystifies me.

IT projects are – at least not after the .COM frenzy, where a bunch of moneypushers tried to tell us the usual rules were suspended – not supposed to burn off the maximum amount of money possible. You are not supposed to build the biggest empire you can. You are supposed to use the minimal amount of IT needed to increase your earnings. Every extra coin spent needlessly on IT eats into the earnings.

Very few companies consistently manage to hit the sweet spot. Some underspend on IT, and increase their costs or fail to get hold of the possibilities that are enabled by IT. People tell me a lot of companies who have tried to offshore development have learnt this the hard way. Others overspend on IT, and reduce their earnings through direct IT spending.

Going far enough in a job ad to say right out that employees are measured by the amount of money they have managed to spend it totally beyond me.

Why would anyone actively communicate that they want the biggest spenders in the class? Even if they are vetting the applicants during the interview process to sieve out the big spenders, the job posting itself sets an unacceptable standard for whoever is already employed, and this mindset is going to take a major amount of leadership to correct. “We have big balls because we are rolling in other people’s money”? In the future of these companies I see people delivering stuff that doesn’t work. The work ethic and the craftsmanship will have gone from the workplace. This can happen all too easily to a development team. When standards slip, they slip fast.

Fixing a culture that has has been degraded in this way reduces the efficiency of whichever leader was just hired, and increases the costs of the project because the other problems – the problems that presumably were there before the job was posted, and is the reason for the role being created – are going to get less attention.

I hope this kind of wording is a kind of slang – a slang created, probably unconsciously, by groups who have worked together in the past. I hope these groups learn to reassess their value in terms of worth. The alternatives are all far worse.

I have been toying around with scala the last couple of weeks. I have read the book, wrestled with the gui, and I am now trying to build myself an application stack.

I think the last gamechanger to appear in the software business was TDD – in the sense of writing tests at all. All of a sudden, a team could accelerate instead of getting bogged down in endless regression tests.

So here I am, having a look at a brand new language, and what do I find? The scala libraries have not been instrumented for testing. A small example: If I send a message to an actor, there is no easy to assert in a test that a message should have been sent (that I can find), much less to access it and test the contents.

I remember way back, when I did hardware. We had something called JTAG. JTAG is basically a series of glorified registers that are placed on all outputs and inputs of a module. In normal operation, the registers just sit there. There is a trivial speed cost of having the extra hardware there, and as such, they are just in the way. Total waste.

But when enabled, the registers come alive, letting a tester sense the input and set the outputs of the register. An ASIC designer can inspect the insides of a fairly complex ASIC. All it takes is a couple of electrical connections on the periphery, and all digital design libraries have these structures. But I am digressing.

In the software world, we lack even this basic test standardization. Every last developer has to build his own test harnesses on top of his test bed instead of leveraging well-tested harnesses written by professionals. The best we have are addons like jmock to help us out. It shouldn’t be like this when we design a new language. We should put this in from the start. I want to be able to go ActorService.enableTesting , which would give me access to all messages being sent.

I wish the day had more hours. I wish I had the time to write this myself.

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.