There’s a number of tweaks to Navigation Plugin, improvements and fixes for Functional Testing (G-Func), as well as some bug fixes for the Authentication plugin.

I’m not sure when I will get time to do these, but they are on my radar. Sadly one has to earn money and plugins don’t generate any (directly). I really want to work on these things but you know how it goes. Good will doesn’t pay the bills!

I was toying with the idea of “crowd-funding” updates to plugins, for specific iterations of plugins that users are willing to pay small sums for in order to get it turned out quicker. I think the model could work… eg 100 people pay $10 to get a new iteration of G-Func released. It could be a new model for open source..

The tools for collecting crowd-funding revenue are already out there for fundraising projects.

Anyway I hope to knock out a new nav plugin iteration in the next week or so, ditto for G-Func. I just can’t promise it

However in recent years I have seen many people – primarily managers – misunderstand the concept.

Agile is about responding quickly to changes in business needs and delivering demonstrable progress to the customer/end user.

Unfortunately some people think that this means saying “Yes” to everything a client asks for, and not actually having a focussed list of deliverables. Agile doesn’t work without planning and prioritisation. All businesses need everything done “right now” if their wish could come true. In real life this is obviously impossible. That’s why prioritisation is critical. Your “must have” list simply cannot be bigger than your development team’s capacity.

Sensible approaches force you to choose a small set of features you are going to implement, and you stick to that. Then in the next cycle you review what the current “highest priority must-haves” are.

If you don’t do this, you have constantly slipping milestones, feature creep, and overworked (and in the end disgruntled) coders who are often forced to hack things instead of furnish your organisation with a sustainable codebase. One that you can refactor, and supports agile development in the long term.

Failure to accommodate this means you get a [fr]Agile environment and code base, where those “must haves” are even harder to implement at the speed your business needs, and quality soon degrades.

Development is just like sustainable living – you have to keep your footprint low and do things with the longer term in sight. Even if you are operating in a truly Agile fashion.

Case 1 – Calling each() on String in Groovy gives you every character of the string… but as a String and not a Character. I’m sure there’s a great reason for it, but it eludes me.

Case 2 – The Java Servlet API is an old friend. The person who put it together however did not understand the concept of HTTP Status codes. To send a non-”OK” response (code 200 as it happens), you have to call a method called setStatus(). However to set the string sent with the status, you have to call sendError – previously there was a setStatus(int, String) but that is deprecated. So… all responses with messages are errors now. OK. Then if you’re using Spring’s MockHttpServletResponse you find they have added getErrorMessage() to get the message set in setStatus/sendError… even though it is not necessarily an error message! Personally I think setStatus(int, String) was fine, and the mock should have getStatus() and getStatusMessage().

Rant over.