Some writing links
10-Jun-09
Not a deep blog post, this one. Just a few links related to writing.
Frank Carver’s musings about software and life
Not a deep blog post, this one. Just a few links related to writing.
A few months ago I made the decision to move the Stringtree and Mojasef code-bases on from their requirement to support older Java versions. I tagged a particular version of the code as “1.4 final” and proceeded to work through the trunk code in the repository to bring it in line with key Java 5 features such as generics, varargs and the enhanced for loop.
Since then I have progressively realized that I may have been a bit optimistic. A few odd bugs have been found in the 1.4 code, and a few key improvements have been made to the Java 5 code which by rights should also be implemented for 1.4. So I have decided to try and fix the situation.
As of today, the tag “1.4-final” in both Stringtree and Mojasef should be considered as deprecated, and any code which used to use that tagged version should instead use the branches (”Stringtree for Java 1.4″ and “Mojasef for Java 1.4″) I have just created. Initially, the code is identical, but the plan is to go through and apply known bug fixes and fully-backward-compatible internal improvements to the branched versions.
In tough economic times with a lot of people out of work and employers cutting back on training budgets few can afford the kind of big-budget, fancy hotel courses which were the staple of corporate training even just a short while ago. So Tobias Mayer has started a no-frills way to get “certified scrum master” status and spread the agile/scrum way of working. He calls it WelfareCSM.
The cost is essentially $50 (to the Scrum Alliance for the certificate) plus a voluntary contribution to cover any room costs etc. Sort out your own food and transport. Even for those of us who regard agile certification as a dubious concept this is pretty tempting.
Reading between the lines, though. It appears that the different agile “camps” may be slipping into a battle for mind-share. If Scrum certification becomes more widely available and understood, then alternative approaches (particularly XP, but also all the other adapted, customized and home-brewed agile working practices) may seem to have less value to employers and clients.
Hmm…
The news was pointed out to me by a friend before I could blog about it, but Google App Engine supporting Java and servlets is a massive move forward for server side Java.
I’m currently experimenting with my own evaluation of this, but in the meanwhile, here’s Michael Yuan’s take on it.
Michael Yuan » Blog Archive » Google App Engine for Java — First Impressions
… if they involve pancakes and beer!
We are currently trying to come to some conclusions about the “shape” of a new software product, and facing a whole lot of problems. Stakeholders are happy to argue for hours about relative priorities of individual features, but so far these exist in a vacuum without an overall vision of a product.
With that in mind we are casting around for any hints on how to map out what we build and in what order. Chris Sims has some suggestions which may be useful, but I’m not sure they address our underlying problem.
Good, thought-provoking stuff. If agile is all about doing what’s necessary when it’s necessary, and not doing what’s not necessary, why should we wait for a retrospective to fix any problems?
Are retrospectives an antipattern? | Steven “Doc” List’s Random Musings.
An excellent point from Andy Palmer. Code which starts out too neat and ordered can make refactoring too difficult. Throw it all in and let the organization emerge from the functionality.
Do you want to get certified in agile software development?
I like to read books, and have learned a lot from reading technical books in the past. These days I somehow always feel too busy to go back and re-read anything I have already read.
Mark Needham and his commenters offer come compelling arguments that it might actually be re-reading which brings the greatest value.
This afternoon, or team had an interesting discussion about our bug tracking system. For some time we have not been happy with the existing bugzilla installation, and the task of finding a replacement has floated on the to-do list. We started to discuss replacements again today, but this time it was different. For about a month, we have had no more than two or three bugs in existence at any one time, and these have been fixed very quickly. Perhaps we don’t have so much need for a bug-tracking system after all?
I was very interested to read that Elisabeth Hendrickson takes a strong stance in this direction too:
InfoQ: Throw Away Your Bug Tracking System?
I think its fair to say that a lot of attempts to “manage” software projects and software teams simply do not work. This is not a new problem, and a lot of smart people have had a go at it.
Recently, software and business pundit Joel Spolsky has waded in, with his take on the importance of a “program manager”.
The team at Energized Work are very upbeat about their process, and in particular how it helps generate real company income every week.
Much of their recipe will be familiar to most agile practitioners, but there are some good extra suggestions, too.
On the one hand this looks like a neat technology. On the other hand it could be more “extreme”.
Cuberick: Pair programming with multiple mouse pointers and keyboard foci
Sure. It removes the bottleneck of fighting for control of a single keyboard and mouse, but there is still only a single screen. So why not use a version of this where each user also gets their own screen. It’s easy, familiar and cheap and works with any operating system – it’s called a separate computer.
While this may seem sarcastic, my point is really that one of the key reasons pair programming works is that it allows each partner to take different a role. While one is “driving” and concerned with the details of keyboard and mouse the other is free to consider larger issues.
I may be wrong, but it seems that allowing both to drive loses that benefit, and plunges both partners into the fiddly world of move, click and type.
Wow, is Test-Driven Developement (TDD) really 10 tears old? Gojko Adzic is blogging the QCon London conference, and has a summary of the TDD lessons-learned session.
Gojko Adzic » QCon London 2009: What have we learned from 10 Years of TDD?.
I’m currently spending a fair amount of time on evaluating distributed version control systems (DVCS) such as git, bazaar and mercurial. Some things which were easy using a centralized version control system such as subversion or cvs seem more complicated, but I am now starting to find ways of using DVCS to do things which the old systems simply could not manage.
It took me a whole evening of fiddling, but I have now set up git to allow me to make chanches to a local version of one of my web sites and commit changes as I feel like it, then when I am happy, send the changes to the live web site with a single git push. This has been working well for a few days, so I plan to roll out a similar structure to the rest of my web sites soon.
Another interesting use for DVCS was pointed out by Francisco Trindade. Distributed version control can help to enable “set based design“. This is a technique where a team samples a wide range of possibilities to converge on a “sweet spot” where market need, business value and manufacturing efficiency are balanced.
Agile development relies for its speed and productivity on making only that which is really needed. Sometimes it can be easy to forget that performance and scalability can be needed too.
Alex Verkhovsky has an incisive post about how to deal with the notion of “premature optimization”.
Thread.current.to_s: The keyword in “premature optimization is evil” is “premature”
How minimal can an agile process really go? Brad Cross has described his lightweight process and it does seem pretty lightweight
Like many teams, I’m sure, we are trying to squeeze every drop of effectiveness out of our time. Manual build and deployment not only takes up valuable time, but also acts as a drag on the development process. Anything which pulls developers out of “the zone” is a bad thing for productivity.
We usually use the familiar “ant” build tool for building deployable artefacts, but have found it increasingly fiddly as our expectations have grown. And ant is hardly useful at all for real-world deployment tasks.
It may be the time to re-consider other build and deployment options.
I love this kind of analogy. Thinking and learning about one area by considering another is a very powerful technique for boosting overall understanding and wisdom. In this case, Steve Freeman has scraped off the climbing terminology from a snippet of an article and replaced it with jargon from software development.
Thought-provoking.