Here we go again

For me, JAOO is the event of the year in the danish software development community.

Last year the buzz was all about functional programming. This years buzz?

Somewhere between cloud computing and self-improvement, combined with pessimistic note

Shu-ha-ri

The best talk was Keith Braithwaters “Techniques That Still Work no Matter How Hard We Try to Forget Them”. He calls himself Old School – old enough to have seen 2 of the 7-year cycles in software development.

Much to peoples amusement, Keith started by announcing, that if IT was a person, It would be diagnosed with
•  ADHD
•  Retrograde amnesia
•  OCD

Things we got right? Nobody has never been as productive as in Smaltalk. 21 years ago. And still is.

There was once a thing called System Analysis … Anyway, somethings wrong with the UML diagrams.

Instead, we should look into how Engineers model:

• Models are useful for what they leave out
• Faster, cheaper than building a prototype
• Models Answer Questions – more quickly and easily than the real thing would

UML diagrams dont adhere to any of these principles …

Architecture Visualization

Michele Lanza , from University of Lugano, Switzerland had a fantastic talk about architecture visualization. Code is text – but we are visual beings. The proper visualization tool should enable us to tell the stories behind the software.

We all know that we should build habitable systems, and that the patterns movement comes from (urban) architecture. CodeCity is the “Habitable” metaphor on stereoids – software packages are converted into cities, classes into buildings, with one floor pr method.

Organizational patterns

This was my moment of enlightenment. I attended the tutorial by Gertrud&Cope about “Fine tuning Scrum”. As well as we have software architecture patterns, deployment patterns, concurrency patterns and … dating patterns, organizations have patterns as well.

Pick a set of them – organize them into a pattern language – and you have Scrum.

Pick another set – and you have XP.

Pick another …

This explains why the thing works – there are patterns underneath.

This made me thinking how this connects to the goals of Enterprise Architecture …

Deliberate practice

Mary Popkins had a fantastic lecture about how we can transform principles of deliberate practice, into the context of software development.

Malcolm Gladwell quotes the 10.000 rule in his book “Success Factors”, and Mary quotes the same research.

10000 hour rule

Any talent which follows deliberate practice for 10.000 hours becomes a Master.

Therefore, we should strive to nurture environments, that let our talents develop under deliberate practice. This requires:

• Find a teacher / mentor
• Practice repeatedly
• Obtain immediate feedback
• Focus on pushing the limits
• Practice regularly & intensely

Thanks for attending our JAOO session/tutorial today. Slides and code will soon be available here.

I attended my first ever software-related conference this week, and it was, of all things, for free as a volunteer! Thanks to Zaynab who introduced me to Lisa Cumes at the one of the Geek Girl Dinners in Sydney.

Behold JAOO, and my first session: a tutorial with Dan North on Behavior Driven Development (BDD).

When we say BDD, a lot of developers tend to think about tools like JBehave or RSpec or Cucumber that encourage the behavior-driven-writing-of-code, writing tests with keywords like it should or acceptance criteria with the given-when-then template. But BDD is about changing the way we think about writing software, about how we deliver software and about what constitutes software that matters and software that has no value.

What are the steps or processes we go through to deliver software?

1. Planning
2. Analysis
3. Design
4. Code
5. Test
6. Deploy

Look familiar? Ideally a software project would undergo a rigorous planning phase to drive out all the goals, then we will run through them with a fine-toothed-analysis-comb to drill out the requirements, and then we hand those requirements over to be typed out into functional design specifications, then further into code, then we dedicate 3 months of intensive testing and finally plop that application into production and let it run oh-so-smoothly!

If you’ve been on any software project, you would know that that is a myth. Projects never run that smoothly, and the best we can do is shorten the feedback cycles as much as we can so we can fix a problem as soon as it arises, integrate often so things don’t blow up in our faces when we try to piece two things together, expect change to happen so we write code that can handle it, etc.

Effort-based metrics are also a myth. Dan gives us this metaphor to explain why:

If you know a full tank of gas allows your car to go 300 miles, if you’ve driven for a while and the meter shows you have half a tank, then you know you have driven for about 150 miles. But if leave the car with the full tank of gas turned on in your driveway, come back the next day and see that it has half a tank of gas left, how far as the car gone?

So how can we measure faster/better delivery?

1. Deliver features rather than modules
2. Adapt to feedback
3. Flatten the cost of change
4. Only focus on high value features
5. Prioritize often, change often

If we are on a 1-week project, when do we know if we are going to be late? Definitely towards the end of the week, or as soon as the week is over. So if we shorten the feedback cycles, we’ll be able to gauge how we are doing much easier.

So how do we get there using BDD?

Getting our words right. We need to identify our core domain but it’s only useful if it helps us identify the problems and solve them. Often we make a mistake of thinking that the object model and domain model are the same thing, but they are not. Our domain is what makes us different in our industry, it is what sets us apart. Dan gave the example of UPS, the shipping company. Fedex and DHL had a very large market share in the shipping industry but UPS pioneered the online tracking system, allowing customers to know where their parcel is anywhere in the world.

Enough up-front thinking. Identify the need. Our outcomes/goals can be broken down into feature sets and/or themes, and further broken down into features/stories and then to individual cards on the wall. We also have to be careful to not focus too hard on the cards on the wall as a one-dimensional line, but keep in mind the big picture of the project/system as a whole and how they relate to the customer’s needs. Fabio has a diagram that visually explains this.

Focus on the value. When we have stories, they can take scenarios, and scenarios can take steps: given-when-then. The event of the story, the when criteria, has to be done from the point of view of the stakeholder so that they get the most value when the story is done.

Agree on ‘Done’. Define acceptance criteria as scenarios. Given the following story:

As an Anesthetist, I want to view the Patient’s surgical history, So that I can choose the most suitable gas

One of the acceptance criteria can be:

Scenario: existing patient with history
Given we have a patient on file
And the patient has had previous surgery
When I request the Patient’s history
Then i should see all the previous treatments

There will be other scenarios for when the patient hasn’t had any previous treatments, or when the history for that patient doesn’t exist, etc. We automate those scenarios and they become acceptance tests, which in turn become regression tests.

Introducing BDD or any new way of thinking or doing things is a big change. We want lasting change that involves influencing values and beliefs. We should look to making those changes with small increments. Find quick wins instead of trying to change everything all at once.

*Note: My favorite part of Dan’s tutorial was looking for doing small increments and finding quick wins when introducing change. He previously talked about transitional architecture where we should view architecture as a changeable entity, if it doesn’t work, we take steps to make it better. Josh Graham also mentioned this point in his JAOO talk, that architecture should be continuously evolving.

Last year at JAOO I had the chance to speak to Markus from Software Engineering Radio about the talk I gave there on Continuous Integration. It’s finally available now over here. The slides that go along with the talk are available from the JAOO site.

I’m very pleased to be able to announce that I’m speaking at QCON London 2009 in March, at the QE2 Conference Centre.  My talk is on Thursday afternoon as part of the Architectures you Always Wondered About track, hosted by Floyd Marinescu.

Unusually for me, I’m talking about the Apex system that I’m the architect for at BGI, rather than more general software architecture topics.  I’m really looking forward to it!  Hope to see you there.

I attended JAOO in Århus this year – what a fantastic experience, this conference has a special atmosphere. Denmark is such a small country, you keep meeting old colleauges, classmates, bosses – whatever.
This years buzz was all about functional languages – we finally need to decide what to do with side effects. One possible solution is to have the language give clear, big warning signs.
This is the old semantics vs syntax discussion: Giving clear names, typesafety etc doesn’t help to achieve the big golden dream of (finally!) having reusable software components. What we need to agree is semantics – what does it do, not syntax – how to call it.
I was enchanted by Bill Verner, and his Scala talk, and I am really looking forward to his newcoming Scala book. A typesafe dynamic language that runs on the JVM – I am kind of convinced that this is exactly what we need. To bad the book isn’t coming out before the conference is over – I would have loved a signed copy.
I also enjoyed Michael Nygards talk “Failure comes in flavors” almost without breath – his rant about patterns and antipatterns when time comes to deploying and keeping our applications alive was full of cliff-hangers. Respect. If you ever have a chance to hear this man talk – and if uptime is of any importance to your next web-app – don’t miss him.
I also spent some time discussing lean/agile architecture with James Coplien and his gang. He is promoting DCI – data, contexts, interaction, which is a new paradigm in structuring your applications architecture. James wants us all to move us away from class-oriented programming to true object oriented programming. We spend a couple of hours hanging out, discussing how to translate his example into different programming languages. I myself tried to convince James that you can do it -in Java too. Sitting together, 5 people, around a table, we discovered how we all have been searching for the same answer. Magic of coincidence, or is it the world allready moving in a new direction?

I just finished watching the excellent discussion on concurrency oriented programming by Joe Amrstrong on InfoQ. I have had both the itch to explore functional programming and the Erlang book by Mr. Armstrong for many months now, however, it wasn’t until moments ago that I realized that my experience with Erlang could not be fairly approximated by my failed introduction to F# and ASP.NET. To be fair, F# seemed to be both powerful and competent. I could not, however, allow myself to return to the confines of programming in the Microsoft community having just experienced enlightenment in the form of the open source community and all that is collectively known as Web 2.0. Having made my reentry into programming with Ruby on Rails, I could not enjoy ASP.NET as a framework, although I can say surely that I would have cheerily chosen F# as my programming language. Having watched the aforementioned presentation though, I must investigate further the mathematics of multi-core processing and take Joe Amstrong’s account into deeper consideration. As the vice president of manufacturing for a CAD/CAM fabrication house, I’m very accustomed to solving bottlenecks in production by staffing appropriately, redistributing resources, and generally solving problems in a manner most consistent with the conceptual model that Mr. Armstrong has recently presented at the JAOO event. While I’ve become quite excited about finally getting to become familiar with some of the newer dynamic languages as of late, I won’t be able to disregard the practical sensibility of concurrency oriented programming without dabbling in Erlang for at least a number of months firsthand. The pursuit of being able to focus on a single grand-unified programming language for web development has fallen short time – and time again – for me these past months, so I’m neither surprised or the least bit upset that Erlang has reappeared in my code-space.

grantmichaels

JAOO 2007: Bob Martin and Chad Fowler – Debating Static versus Dynamic Typing.

Um vídeo de 35 minutos com Robert C. Martin e Chad Fowler no JAOO 2007.

É sempre bom ouvir alguém como Robert C. Martin – Uncle Bob falar

Aqui está disponível uma pequena entrevista com 11 minutos, onde ele fala que atualmente ainda existe *muita* coisa horrível sendo produzida, códigos que não deveriam ser escritos. São práticas que são conhecidas a muito tempo como sendo práticas ruins e mesmo assim continuam sendo utilizadas.

Depois ele fala sua opinião sobre desenvolvimento de software ser um engenharia, segue falando sobre TDD, um pouco sobre como Java, .NET e Ruby e como os códigos desenvolvidos nessas linguagens são/podem ser mais fluentes/expressivos… e por aí vai, é uma entrevista curta mas com bastante conteúdo