“Ah, that was a nice bowl of cereal and mug of tea. I’ll just clear these off my desk now.”

“Oh look, a nice clean kitchen…hmmm… I’m in a bit of a rush so I’ll just leave my stuff in the sink. It’s only one bowl and spoon. The cleaner will wash it at the end of the day anyway”

Lunch

“Ah, that was a nice sandwich. Let me just take this plate to the kitchen.”

“Oh, the sink is filling up…hmmm…I really shouldn’t add to that pile of dirty plates, but I’m in a bit of a rush, so I’ll just put it here on the side. It doesn’t make much difference, it’s just one plate on a pile of plates”

Afternoon Tea

“Oooh, I think I need a drink. Let me go and make something.”

“Oh, there aren’t any teaspoons left…hmmm…they’re all at the bottom of the sink under a pile of dirty crockery and cutlery. Well, I’ll have to just dig one out, wash it, use it, but as I’m in a bit of a rush, I’ll just put it back in the sink.”

P.S. Why is the first C in CITCON a hard C?

Simon’s talk mentioned that an architecture is produced by the combined forces of requirements, constraints and principles. Software architects need to be flexible in applying principles to the right situation. Keith’s article is also in this spirit (they both talk about “T” shaped people!) and blind application of concepts and principles can produce something that is of very little value. That delivering business value is the goal, not architectural perfection.

My experience over the past few years however, takes these pragmatic ideas a bit to the extreme. Abandoning good principles and practices over the long term to satisfy the business. In my opinion this isn’t sustainable. I’d equate it to a house that has the perfect living space, the most comfortable furniture, but wicked subsidence.

Of course I tend to paint a grim picture sometimes. The fact is, the business got to where it is today because of the sacrifices made in the past, this can’t be denied. We need to work on our technical debt and move to that utopian middle ground, where software engineering principles meet business value.

Something we’re still trying to work out is how to quantify this debt in a way that business people can understand (bugs == £££?). We’ve started cataloging ugly code and tracking quick fixes and trying to evaluate their long term impact. It’s all about trading time to build marketable functionality, for time to underpin the foundations.

I agree with Simon and Keith. Principles are there to guide us, and we should use them when necessary. The techie within me though is crying for just a bit of professional integrity!

Another thing Simon introduced me too…the project triangle. I liked that

With Toyota boss Akio Toyoda telling a US Congress committee that his company will make a ‘double commitment’ to safety and its customers, I have to wonder what happened to bring this very public failure in quality to Toyota.

Of course I think statistically it may be a relatively small failure. This is probably more hype and PR than any real issue. No doubt the American car manufacturers are loving it.

Always tough to decide which session to attend. I ended up in keith braithwaite’s session on the use of bayes’ theorem to prove if there are enough tests for a system.

It was quite heavy for me that early in the morning but was very interesting no less.
As I understand Keith wanted to put out this idea he has of using bayes theorem to calculate the probability that, given an initial probability that the code is correct, how much will additional tests prove that the code is correct.
What I liked about this was the idea that we could quantify our confidence that code is correct. however we did discuss that our initial assumptions could be incorrect and subject to second order ignorance. establishing the initial probability can also prompt more discussion between developers and QA.
I think Mike would have loved this discussion ;-)

Just finished a lighting talk session. one of the talks that stand out highlighted that many in the agile community have strong ethical values, yet work for companies that don’t have ethical goals…food for thought

After google’s keynote, there was a session by New Bamboo about practical agile tools.

* They constantly ask if there is a better way

* Use low tech solutions (Sword of integration made from rolled up newspaper)

* Scrum master task list, which looks like a handy way for someone to manage multiple agile projects

* Heatseeking actions – A good way to well define actions from retrospectives (we need to start doing more retrospectives “back home” and this is a good practice to follow)

Anna’s session on When Agile might not be the best solution provoked a lot of helpful debate. there will be a followup OpenSpace at somepoint. Lots of good feedback

After lunch there was another experience report coding dojo by Emmanuel Gaillot. I’ve picked up quite a few good tips from this and will be applying them when I start some internal dojos.

Finally there was a session by Gojko Adzic (still have to finish reading his book!) on Building software that matters. It’s good to hear that some of our practices with building user personas is something that loads of people are trying to do.

Below are some steps devs could follow, initially with supervision, for working on a fix/enhancement where code can/should be cleaned.

1. Document existing behaviour of the particular area for acceptance criteria (if we agree we can work with FitNesse, then this would just be documented in FitNesse wiki form).
2. Clean the code around the area of the fix/enhancement, implementing unit tests.
3. Verify that the refactoring hasn’t broken existing functionality using acceptance criteria (run FitNesse tests).
4. Update acceptance criteria with new requirements for the piece of work (not necessary if the piece of work is not changing functional behaviour).
5. Update/create unit tests for the code changes.
6. Implement the fix/enhancement.
7. Validate unit tests pass.
8. Validate against acceptance criteria (run FitNesse tests)

This is a bit of a “test first” approach, however we still don’t want to enforce TDD at the unit test level, so I guess it can be left to the developer to decide how to implement the fix as long as there are unit tests with good coverage at the end of development, and they all pass.

With acceptance criteria, I think it is best to establish how the system currently works and how the system should work before making changes. If we can’t use FitNesse, then the “validate against acceptance criteria” parts will have to be manual, where the dev runs through the working system.

All of these code changes will still need to be validated by system testers, until some point where we have collaboration between dev and test perhaps around acceptance tests.

How will we deal with this increase in both dev time and test time? I hope that management can still see the value in this investment.

As long as it is accounted for on a project plan somewhere, it seems that management will be OK with developers spending that extra amount of time and effort in writing better code. But this will be hard to estimate for initially, seeing as we’ve not estimated for things like writing unit tests, refactoring or pair programming before.

We’ve begun looking at various ways of improving our estimation process. Planning poker seems to be quite popular. It will still require individuals to consider the time it may take to work in a way they have little experience of. This will undoubtedly lead to inaccurate estimates for the next few releases. As we seem to agree it is better to over-estimate (if that is indeed possible) then my advice to my fellow developers is…

Double your estimates, then double them again.

Unit testing is something quite high on our quality agenda. All devs have been told to start providing estimates with time to write unit tests. (don’t get me started on estimation!) Problem is many of our developers are not very experienced with writing unit tests. This may be a steep hill to climb. The plan here is to start as easy as possible with internal workshops and coaching from the more senior developers.

Pair programming sounded good, but honestly we can’t force it on our devs, mainly because it would halve our development team. And I’m not thinking in a manager, “2 developers to do 1 task” kinda way, I mean one half of the team would probably kill the other half…or quit…or both… No, a flexible “if it helps” approach to pair programming is favored here.

Other issues we didn’t quite have time to discuss were documentation levels and possibly looking at Kanban for our issue management process. See a great intro to Kanban at Karl Scotland’s blog.

This is going to be a pretty slow process, which in a way is good, as it gives me plenty of material to blog about