19 november 2009

Devoxx 2009 - Day 4: keynotes

Today's keynotes were not the technical kind of eye candy stuff, but nevertheless really interesting and absolutely necessary.

Ivar Jacobson

The first talk was by Ivar Jacobson, co-founding father of UML (1 of the 3 amigoes). He started with the influence of fashions in IT. About 10 years ago everyone started doing UML. 5 to 7 years ago CMMI was the way to go (especially for managers). And then, 3 years ago, there was eXtreme Programming. And now hardly anyone talks about XP, but Scrum instead. He didn't mention this, but also Scrum is getting out of fashion: now there is Kanban...

Then there is the gap between methodologists, industry and academics. Especially industry and academics don't really like eachother: academics in the eyes of the industry have never delivered something useful and the other way round, the industry doesn't understand what the academics are doing.

As far is methodologies are concerned: there are some many methodologies in the world. Every company has its own methodology. And they all steal from each other. They pick parts from each other, which results in a soup of methodologies... Methodology nowadays is very much a religious discussion: you either believe in and follow the entire methodology (e.g. Scrum, XP, RUP or whatever). But what they basically do, is pick some ideas here and there, add some stuff of yourself and then write a book...

Knowing all these problems, there is a big need for 1 theory of methodologies, away from fashion. We need to refound software engineering based on solid theory, proven principles and best practices. In other words: no more processes, but practices instead. So not RUP, but the practices of RUP. It should deal with both technology and people. And finally it should support extension in face of changing requirements and technology.

This resulted in the creation of SEMAT: Software Engineering Method And Theory. This organization is joined by a number of people of all involved sectors: industry, methodologists, academics.

These are the names of people involved in SEMAT:

Pekka Abrahamsson, Scott Ambler, Jean Bézivin, Dines Bjorner, Barry Boehm, Alistair Coburn, Larry Constantine, Erich Gamma, Tom Gilb, Ellen Gottesdiener, Brian Henderson-Sellers, Watts Humphrey, Martin Griss, Ivar Jacobson, Philippe Kruchten, Stephen Mellor, Bertrand Meyer, James Odell, Meilir Page-Jones, Ken Schwaber, Alec Sharp, Richard Soley.

Note the presence of the following people

  • Ken Schwaber, the man behind Scrum
  • Alistair Cockburn, the author of the book Writing effective use cases
  • Scott Ambler, the man behind Agile UP, Agile modeling and stuff
  • Erich Gamma, one of the Gang of Four (design patterns), developer of JUnit, Eclipse and Jazz
  • Ivar Jacobson (off course)

All these people know what the problem is, but... they all have a solution to it. Their solution. But this group is not only about finding a solution, a consensus, but also about community, Get everybody's best practices work together, not new practices or "best" practices.

The basic idea of SEMAT is based on a kernel. This kernel is sort of a language to define practices:

  • things to to
  • things to produce
  • patterns to apply
  • competences to apply

The kernel should be used to harvest the best practices, see how people use them and for what. Then some practices may be replaced with other practices that may fit better.

Imagine how organizations adopted methodologies like Scrum: many threw away the good practices along with the bad. That's not smart... It is better to gradually introduce practices that work.

On the academic side, people are rewarded for the volume of paper they produce: the more papers they write the more important they are... And students don't really learn what is really useful for the industry. Therefore they should study the kernel and a set of good practices.

Finally, methodologists write book. People buy them, but don't read them... Authors travel around the world to tell what's in the books ;-) Instead of writing books on new methods, they should stand on top of the kernel and its core practices and add their own.

More information: www.semat.org

Robert C. Martin (Uncle Bob)

The keynote of uncle Bob was very animated. His basic idea was that developers still face the same problems as 40 or so years ago, no matter how technology has evolved. Developers and developers still hate eachother: developers still deliver their software too late and management keeps promising unrealistic things.

We should ask ourselves: what is software development? Do we consider ourselves as professionals? Software development should be about craftsmanship. We should be proud what we do and on how we do it. We should deliver good work. But the biggest issue to face is that we should find out what being professional means. And that means in the first place learning to say "No"! Not "I'll try". Professionals, like doctors and lawyers, stand up for their principles. They don't cross that line, they don't compromise. Developers see themselves too much as blue colar workers, being paid per hour.

Another problem is the tendency to promote good developers to management functions. That seems to be the only way to have a carreer. Many companies don't offer a technical specialist carreer path.

As a reaction on this, as a call for action, the manifesto for software craftsmanship was defined. It looks a lot like the agile manifesto and it builds on the fundamentals of the agile manifesto but goes one step further. The aim: have a productive partnership with the management (in order to get rid of the mutual hate).

The manifesto defines a number of ethics and practices, of which a few are mentioned here:

  • do no harm!
    • not to your customer
    • not to your company
    • not to your colleagues
  • clean code
  • to go fast, go well (if you do something good from the first time, you win time)
  • test driven development
  • 100% test coverage
    OK, really 100% code coverage in unit tests is impossible, but if your unit tests guarantee 80% code coverage, this means that there is 20% of your code of which you're not sure if it is working or not!
  • KNOW it works (by code coverage)
  • Green bar = shippable
    QA should find NOTHING! If they do, the developers should ask themselves what happened and act upon it!
  • QA = specification, not verification.
    This is the definition of "Done", not a huge document that should be tested manually after the development is done.

Uncle Bob's talk was sometimes confronting, but the message was clear: become professional, learn to say "No", don't compromise on your principles and deliver quality!

More information: manifesto.softwarecraftsmanship.org

17:03 Gepost door There's more to life than what you see through windows in Javapolis | Permalink | Commentaren (0) | Tags: devoxx09, keynote |  Facebook |

De commentaren zijn gesloten.