Firstly, I found the second day much better than the first. I did see Michael Nygard’s two talks on Monday morning and got a lot a lot of useful information from those. Titled ‘Failure comes in flavours’ the first was a great overview of the types of failure that applications running in production encounter, the second ways to avoid those failure modes. Basically it’s how many of the non-functional requirements can eat your app (and even the entire integration if you let the failure propagate easily) if you don’t give careful consideration to them. He’s got a book so I’m going to check that out next.

The first day for me was severely spoilt by a poor vendor presentation (hint: one that is not Oracle, not that they would have necessarily done any better), which I should have known better to avoid. I already swim in the BPEL/BPM/SOA soup, I fully understand just how broken it is as an actual development concept (e.g. anti-test-first to name just one). I was fooled by the title to thinking maybe it had some insights to avoid the worst of these busted concepts, but no, the vendor’s tooling is all the rage if you drink the poor-tasting conceptual kool-aid. This stuff is marketed at managers and non-coding architects who choose to buy this stuff then dump it from a very great height into the laps of the poor developers who have to mangle it into a deliverable system (half the time with a development budget just a tenth the cost of the licence). Anyway back to the good stuff.

Mike Cannon-Brookes from Atlassian (which makes great development tools, highly recommended) gave a mostly great closing speech on the first day which made me think about a couple of things. It wasn’t until the next morning however that it crystallised in my mind. It’s a bit of a minor criticism.

Mike threw out a minor line, an aside really, talking about Atlassian’s agile development methodology, and basically that said, people who say ‘you must do this’ are wrong, because they miss your context. Here ‘this’ is some type of agile process artefact like maybe, pairing, or estimating in story points, or whatever. Well, it’s wrong and on two counts. The first count I realised just after the talk but couldn’t articulate it correctly in semi-drunken conversation. That first count is very simple. Mike’s timeline on his Atlassian experience has him, if I recall correctly, starting his company and creating the great tool Jira, in his early twenties. Now as he dissed “old people” in his talk I’m going to give some back. In your twenties you’ve got no idea what works, in a general sense. You might know (or think you know) what works for you, but that’s a completely different kettle of fish to what works generally. Why not? The word is experience. Its not until you reach … oh … I’ll say around 35 (and so maybe lose the capacity to build technical innovation, perhaps, as Mike asserted) that you can have real insights into process and people. It’s just because at this point, you just have not got enough practice at it (see Malcolm Gladwell’s recent book for some basic data about the power of practice).

But the bigger point I think is the word context. The phrase ‘my context is different’, is this classic phrase which really means ‘that won’t work here’ and that really means, I don’t want to change. As a consultant , you hear this stuff all the time: … “We’re unique, our company is not like those other companies. We can’t do that here. Detailed estimates are really the most important part of the development process. The budget and the features must be fixed. We have a reporting process that allows the budget and features to be fixed. Pair programming doubles the time it takes to deliver the features. Quality doesn’t matter. Technical quality is a business decision. The business are too busy to talk to you.” … And a whole other other bunch of epic agile fail. Someone’s context is exactly why they aren’t as agile as their competitors and are looking at using ‘agile development’ to help save them … but as long as they insist on my context trumps all, they will only get a fractional improvement and not an order-of-magnitude one. But Atlassian make great products, so it doesn’t mean you have to have ‘scrum’, or ‘XP’ to do that, the greatness I guess, is orthogonal. However if you are looking to ‘do agile’, then do agile. Pick a method like Scrum or XP then do it all. How do you know pair programming will fail in your organisation if you don’t try it first? You don’t. Do it like it says to do it (e.g. the Kent Beck books) and after a few months experience for your team, use the lessons from the retrospectives that the team has discovered to improve the process. Do not cripple the process with your ‘context’ before you even try.

And right on cue, on the second day along comes Steve Hayes with a great presentation on exactly this topic: “How your choices affect your agility”. Steve is a fantastic speaker, entertaining and pretty insightful too I thought. I rated his talk the best talk of the conference. He said he got lots of red cards (participants could rate each talk as green==good, yellow==ok, red==bad) in his Sydney session – what is the matter with your people? It was a great talk. I loved the part about naivety. To propose a solution from the most naive perspective possible, and what an epic win it is when a customer says “ok”! It means I understand the problem! I even tried this today with my client, I didn’t get the instant “OK” but working from the basis of that incredibly naive solution we did manage to eventually envisage the simplest thing that could possibly work. And I love that. So thanks tons for that insight, Steve!

Another great talk on the second day was Linda Rising’s ‘Deception and Estimation’ talk. Turns out (via psychology and evolutionary biology) we engage not in rational decision making but in emotional choices all the time. All choice is emotional. So we engage ourselves in self-deception all the time. And none of this is bad … it’s good. People who don’t engage in this constant self-deception are generally clinically insane. So get over it, and yourself, and when you’re estimating (and from the sounds of it, doing any sort of major-impact decision making) and get as many perspectives as you can from the most diverse range of people you can manage (to avoid groupthink, which is I guess, the situation where everyone’s self-deceptions all align). Joshua Bloch’s second-day keynote was also highly worthy of praise. Good insight and excellent effective code examples (yes, in a keynote). Also worth the greatly discounted entry ticket price was the many interesting conversations I had with past colleagues and new friends on many different development issues.

In short, JAOO was generally of very high quality and I hope is keeps coming to Brisbane! Will definitely be going next year. Many thanks to all the organisers, presenters and sponsors.

“Oh, my God! You’re going to let a sprint fail, just so you can determine the optimum length?” Yes.

In other words, failure lets you learn your limits. But more importantly, as suggested here, is that failure can be deliberately introduced in order to improve the process – to decrease your limitations. I would say, for an organisation committed to process optimisation, you should shorten the sprint until it fails, but rather than just accepting that limit, learn why it fails and then experiment with optimising it until it succeeds. Let me explain.

Courtesy of a tip from Doug South at the Brisbane XP user’s group, I’m nearly finished reading a book at the moment, Chasing the Rabbit by Steven J. Spear of MIT and formerly of Harvard. The book’s full title is Chasing The Rabbit: How market leaders outdistance the competition and how great companies can catch up and win. It’s a business book that describes the essential feature of successful companies such as Toyota and the Toyota Production System.

Before you roll your eyes and think I’m just another one of these lean software guys who’s about to rave over kanban, kaizen, and just-in-time, and applying manufacturing production-line process, possibly inappropriately, to the professional practice of software development, let me assure you I’m not. Neither does Spear. Basing his book on years of hands-on research into these high-velocity organisations (including time spent actually working on real production lines) he characterises kanban and friends as merely an artifact of a deeper philosophy towards building a successful company. In some ways its breathtaking simple, although hard to practice. The theme of the book is discovery.

The factory was not only a place to to produce physical products, it was also a place to learn how to produce those products and – most important of all – it was a place to keep learning how to produce those products. In fact, this is exactly what so much of the early research about Japanese management had revealed – that learning and discovery were intrinsic to success. But that idea had gotten lost as people focused on the particular tools and artifacts used in the workplace at the expense of understanding the principles of how those systems where managed. (p 15).

These companies don’t succeed or fail. They succeed or learn to succeed.

Now it is of course slightly more complex that just that. There are two characteristics and four capabilities that high-velocity organisations exhibit. The four capabilities are:

1. Specifying design to capture existing knowledge and building in tests to reveal problems.
2. Swarming and solving problems to build new knowledge.
3. Sharing new knowledge throughout the organisation.
4. Leading by developing the first three capabilities.

Now these capabilities can be developed – in different manifestations – in any sort of process, not just production-line processes. Spear shows it in action in health-care, in nuclear engineering, in aluminium production, and of course automotive production. I’ll into further detail perhaps in a later post. Here I’m going to discuss a simple example illustrating not just capability 1, in which a process not only captures knowledge but has built-in tests, and also capability 2, involving problem solving and process improvement, where the process is tested to failure, in order to reveal what knowledge is missing about the process.

In the book he describes a mattress factory, Aisin, that, after a long capability improvement process ends up with two production lines each capable of making (e.g.) 100 units a day to custom order. On some given day, imagine they have a requirement to make say 180 units. Rather instead of running one line at 100 the other at 80, or both at 90 units, they will instead deliberately overload one of the lines (e.g. ramp it to 110 or 120 units) in order to discover the process failure modes (that is, the process’s bottlenecks) so as to to improve them. They already know how to make 100 units a day. They can learn more about their process if they try to make 120. The reason they do this on days of lighter loading, is that the can use the unstressed production line as a back up, if the test was too stressful for the line under test.

Experienced software engineers might recognize this stress testing from their performance testing toolkit. Loading a software system to the point of failure is one quick way to learn where a system’s bottlenecks are, and what to do about eliminating them, and thus making your software architecture more efficient, and discovering new knowledge about how your architecture performs and what needs to change.

The point is of course, I’m not talking about stress testing software. I’m talking about stress testing software development methodology so you can discover what you don’t already know about your process, and therefore improve it. I don’t mean, just arbitrarily place more demands on your software teams to produce more with less. That’s just the most retarded type of management-by-objective.

Think about all the moving parts in your development process. What do you know about them? What do you assume? What do you just take for granted? How much do your team members know about the process? Can they identify problems and propose solutions? Do they need to learn that capability? Where are your failure modes? Do you just accept them, and perform a work around, or do you understand them as signals to elicit further discovery about the things you don’t understand about the process? Embrace failure. In fact, actively seek it out. Use it an opportunity to discover unknown information about your business and to improve your team’s skills.

Chasing The Rabbit is a great book, highly recommended that all software development practioners read it, and special thanks to Doug for bringing it to my attention.

Anyway it turns out that Kent is writing a product called JUnit Max which looks super interesting for those using the discipline of TDD to write better code. Look at the Flash presentation on this page: http://www.threeriversinstitute.org/junitmax/subscribe.html … Also it brings together another thread we had on the mailing list which was about Eclipse’s incremental compilation features. This is incremental test running!

A pity it’s not free but I guess Kent’s got to eat. I might be tempted to buy it in the near future.

Every few years a vendor, or a group of vendors comes out with some bright idea to allow some class of end-user, or business analyst, or what have you to build their own systems, in recent years usually by some type of graphic language (draw your system’s program flow right on the screen! bypass those pesky, and expensive, programmers who just ask confusing questions and force you to clarify your thinking!  press the magic ‘deployment’ button and your half-baked idea is in production in seconds!). In the past, these systems used “natural” language or “plain English”  languages such as say Director Lingo.  Every few years it moves onto some new paradigm or expression of the old one. And it always just ends up simply with a whole new class of programmers being created.

Do not trust any product – or standard – that promises to deliver “programmerless programming”. Plenty of 4GLs like SQL and the like are originally meant for non-programmers to use … imagine giving a business user just a SQLPLUS prompt now! Included in that mix there was CASE … a recent example from the past few years I can think of might be BPEL and ESB style tools, or for another example a number of attempts to define architectural languages that generate the system components for you off the UML or similar.

A big issue I see with these systems is that they tend to be highly resistant to modern programming principles and practices. For example, test-driven design – or even simple unit testing. Sure, if you’re building a web app with these things, maybe you could use a web-testing framework to build functional tests and build-to-pass. But most of these tools are very resistant to a test-first approach.

Take Oracle’s BPEL tooling. For a start, you’re forced to used JDeveloper, which is a crap IDE you’d never otherwise inflict on yourself (it is so bad, on start up it displays the most meaningless product slogan I’ve seen seen on such a tool – “Productivity through Choice”). But more than poor tooling, the very paradigm is completely broken. Forget about a test-first approach (although I’m sure there’s some seriously weird way to achieve it), just try setting the damn tools to have the traditional development, testing and production environments. When ever you need to call a service end-point, you are bound to the particular host and port you specify – it’s embedded in XML document that represents the BPEL design. The workarounds? Well if you are super organised you could arrange for your different environments to contain identical setups and  use DNS hacks (or host files) to ensure that each service looks the same when you move from development to integration testing to production. Or you can write Ant scripts (or sed and awk if you really want) to search-and-replace the offending hostnames and ports and replace them with the correct values for the target environment. Clearly, once you use it, you see that the tool’s paradigm is, in reality, to just hook up the IDE to the production server, draw your pretty flow chart modelling your business process, then publish it straight back into production. In other words, there’s a whole new class of programmer out there now – BPEL programmers – and life must be a nightmare for them. Its fundamental paradigm is broken. Given me any language with a unit test framework with a half-decent programmer on any day of the week, and you will beat the pants off this system in productivity and choice. It’s living a lie – and a big one.

Ultimately, as each new generation of “programmerless” program-construction tooling comes along, it allows developers to do more powerful things (and sometimes, less powerful things in a more retarded way). And the scale of the task always increases to the point where development specialists are still needed. In my view, there is a definite on-going role for for the talented programmer/analyst who knows how to take a vaguely-worded, incomplete, and contradictory bunch of requirements expressed in common verbal language and then ask the right questions in order to clarify them and decompose the requirements to a series of simple logical components – and then develop and deliver those components in the form of usable systems. You need to continuously learn new languages and systems, but the basic skills stay the same.

I have found too many code bases over the years, with bolted-on, after the fact tests, plagued by spaghetti code and strongly coupled components to be that naive about unit tests. Sure people pay lip-service to testing, but I think many programmers haven’t yet found the value of test driven design in their professional practice. I know enough that I come across this situation frequently. “Oh I’ll do the tests later”, “I don’t have time to write tests, I have to write code!”, etc. Heck, I am sometimes still guilty of it myself. Here’s some rolled-gold reasons Bain gives to pay particular attention to the discipline of unit testing in a test-first scenario:

• It reduces bugging time.
• It makes the development process more predictable – finding bugs often exhibits non-linear unpredictability.
• It encourages appropriate coupling, ensures cohesiveness, and reduces redundancy.
• It makes you think about your code in more depth.

I must say, even when confronted with an existing code base that has little to no unit testing, it’s always advantageous to start writing the tests before you start fooling around too much with the code base. It will help you discover the design weaknesses.

Another point I have to make about unit testing, is that whenever I need to evaluate a new technology,  I now use the ability to utilise test-driven methodologies as an important criteria. Especially if that technology is supposed to be a productivity-booster for programmers. If I can’t write the tests first, then I just know the tool, or technology, is going to produce less than optimum results – how can it make any programmer more productive if it removes the ability to write code until the tests pass? And if I can’t write any tests – that is it has no test framework either built-in or freely available, then I just know the tool sucks, and is to be actively avoided and recommended against. I’m especially suspicious of technology such BPEL frameworks and other frameworks designed to provide “programmer-less programming” (but that will have to wait for another day).

Emergent Design: The Evolutionary Nature of Professional Software Development by Scott L. Bain

Amazon

[E]mergent design works by refactoring and enhancing code, due to the changes, bugs, and extensions that have to accommodate, while paying close attention to these principles of coding. (152)

In order to deal with the idea idea of evolutionary software development with a lean or agile methodology you have to first grasp what software development is and isn’t. As a consequence of this, the first part of the book deals with the idea of “Software as a profession”. A lot of this is very thought-provoking; I’ve never really thought about what a ‘profession’ actually is before.

Software development has not been around for very long, in the grand scheme of things. Other, similar complex endeavors (medicine, the law, architecture and so on) have been around for hundreds, even thousands, of years, and in that time a whole set of standards, practices, and general wisdom has been captured and handed down from generation to generation. This has helped to increase the rate of predictable success for each new batch of doctors, lawyers, and builders, and in each case has led to the formation of an organism we call the profession.

Although he admits that the choice of development as profession is somewhat arbitrary, it does serve to highlight that what we do as developers is like no other activity. In other words, software development is a unique activity, and there’s no point in organising it using the methods of electrical or mechanical engineering, research science, medicine, or house building. Each of these professions is different from software development and different from each other. Software developers need our own ways of organising our field of knowledge, some of these are currently absent.

Features that need to be covered in software development as a profession:

• Specialised language. This would be at a high level, not a low abstraction level like at the code itself. Bain maintains that the design patterns ‘movement’ is a move towards the development of a high-level specialised language that matures our field towards professionalism.

• A clear entry path. Something that’s currently clearly missing, although I’d contend that perhaps a computer science or information technology degree and employment as a graduate programmer, at least in this country (Australia), is something that somewhat fills that role.

• Peer-review. Peer review is fairly ad-hoc and chaotic, despite attempts at things like user groups and websites.

• Standards and practices. Unfortunately there is little agreement amongst the broad software development community about ‘what is right’. However, I would argue that the Agile movement is at least a move in the right direction.

The sorts of things that need to be discussed and understood by a profession of evolutionary software development might number:

• Qualities. How do we know when something is good? How do we choose the best thing? What is meant by best?

• Principles. The fundamentals of good software. “Principles promise better results in terms of the qualities we will emphasize”.

• Practices. The things you do in your daily coding activities. Practices must be easily taught because they “are truly valuable when they are shared and promoted to all the developers on a team”.

• Disciplines. These are similar to practices, but on a larger scale. Things you should do that have a basic and profound value to what you do as a developer. For example, unit testing, refactoring, test-driven development.

• Patterns. What worked before; “the set of interrelated points of wisdom that reflect what [the profession knows] about certain situations … that we find ourselves in again and again”. I would add, and the common, standarised jargon that we use to describe and discuss these patterns.

• Processes. How does development work? How do we know what to build? How do we know when we’ve built it? How do we correct the situation when we discover something’s wrong? How we we discover that something is wrong? Et cetera.

In this day and age I can still find developers, usually working in crippled environments, who won’t even agree on the simple principles of maintaining ‘good’ code practices, for any version of good. Whatever’s there, they’ll accept. Even when faced with seriously broken design, and a mandate to effect change, a cascading series of ever-fragile hacks will be accepted, even if it takes more time to produce, or modify, the hack. Code will never be deleted, even long after obsolescence. It is left remaining, “just in case”, and as if there was no version control system.

As a consultant, I have no real choice but to work with these programmers. I can only try to encourage them to follow a right path. I was recently told I was a perfectionist, simply for demanding any level of unit testing greater than 0.