Lessons Learned from Java EE

Lessons Learned from Java EE is an interesting presentation by Rod Johnson.

Here the most interesting/provoking points:

• The fallacy of love for complexity: "No pain no gain" does not apply for software. Powerful solutions do not have to be complex, the opposite is true!


• Tools cannot conceal excessive complexity!


• The myth of the code monkey: Developers are dumb. They have to be protected from having to make decisions. -> The result is excessive complexity.


• The need for an over-arching (enterprise) strategy means that common sense is thrown out the window.


• Complexity is an expensive luxury - in economic boom times people are happy spending money for complexity but economic downturns tend to reduce complexity.


• Developer empowerment is an ongoing trend:
  • Because things change quicker than in the past, and management need to rely on developers more
  • Open source allows participation
  • Expensive, complex portfolio solutions/tools did not prove to be successful/productive
  • Agile development is a developer-led initiative
  • The Cloud is shifting the balance between operation and development

My posts around these topics:

	The Antipattern of Framework- vs. Business-Programmers			Essential, accidental and fabricated complexity
	Visual modeling: Is it worth it? An example...			Creativity and competent People
	Michael C. Feathers: Seven Blind Alleys in Software Design			Java EE: The blue pill of enterprise development?

follow me on twitter, I need some friends :-)

Scrum Master Certification in Zürich with Mitch Lacey

February 8. and 9. Mitch Lacey is running his Scrum Master Certification course in Zürich Switzerland.

If you are thinking about getting the Scrum Master Certification, I can fully recommend Mitch's course.
I did attend his course in Vienna last autumn. Those two days were very interesting, informative and never boring. Mitch really is a great teacher and story teller with a lot of practical experience.

If you are interested you can find more details and registration here.

Update: On TechTalk's Mind hosts a podcast with Mitch discussing Scrum in fix-price projects.

follow me on twitter, I need some friends :-)

The risk of scrum

Last month Ralph Jocham gave a talk about the Risks of Scrum.

He published the slides on slideshare: Ralph Jocham The Risks Of Scrum.

As far as I understood it, Ralph identified two Risks with Scrum:

1. Not doing it right or not practicing it to the full extent
2. Neglecting technical excellence and accumulation of technical dept

The first one is a bit a platitude in my opinion. Any failure can be blamed on not doing things right... of course with methodologies that consist of several parts, there is a danger of cherry-picking, but I am not sure that this can't work. I think it's also often a cheap excuse to put the blame for a failure on "not doing it right". I mean, who is really doing it right? How many of the successes are doing it right?

According to Ralph the second risk should be met with XP practices that focus on technical quality.

But in my opinion there is a much more fundamental danger in scrum:

Scrum gives the impression that it is possible to bring "Embracing Change" and "Getting Things Done" under the same umbrella.

This is dangerous. "Embracing Change" and "Getting Things Done" are two opposing forces. On a certain level it is inherently not possible to get things done while embracing change.

Scrum as an agile methodology is all about embracing change. With the focus on the Done-Stage on the Taskboard and the "Definition of Done", Scrum claims that those two opposing forces are actually not opposing. This is in most cases an illusion.

This is mostly a result of focusing on small stories with immediate business value. Getting these stories done is possible, and Scrum can easily misused as an "excuse" to neglect the big picture.

Progressing in Scrum means getting stories done. Often the real progress of a finished story in regard of the whole project is not measured...

A symptom of this antipattern is that certain things get touched and changed again and again by new stories in subsequent sprints... so what was actually done, the story or the real business problem?

Shortening sprint duration and focussing on smaller user stories can even aggravate this problem ...

follow me on twitter, I need some friends :-)

Testing Backlash: Recent, well grounded opinions questioning the value of TDD and unit-testing

It is 2010. I declare that #TDD is no longer controversial.

Uncle Bob Martin on Twitter

We all know the Gartner Hype Cycle for technology adaption:

Sometimes I wonder where on this curve we are concerning unit-testing and Test Driven Development (TDD)?

Just recently there seem to be a movement to the "Through of Disillusionment" with several fairly well grounded articles questioning the value of unit-testing and Test Driven Development (TDD):

Problems with TDD an Essay by Andrew Dalke. Heavily discussed on his blog and on Hacker News.

Chris Ashton's post: It's OK Not to Write Unit Tests

Ayende's posts: Even tests has got to justify themselves and re: Are you smart enough to do without TDD

And finally Luce Francis brilliant presentation: Testing is Overrated (matching blog post, slides)

On the other hand there seems to be prove that TDD is valuable:

Empirical Studies Show Test Driven Development Improves Quality

Maximilien-Williams study

Uncle Bobs TDD Triage

follow me on twitter, I need some friends :-)