I really like using graph paper to draw UI designs on, and for just about everything else. Now I can get my graph paper via the office printer and not OfficeWorks ! I hope this is of use to you.
Thanks konigi !
I use Complexian in my Java work and it is simple and fantastic, and now Marty Andrews has released a tool similar to Checkstyle but for Ruby. It is called Roodi. I’m sure this will be another simple and fantastic tool. Check it out here on Marty’s site. Btw - Thats Marty in the pic.
While re-reading Chapter 8 - Agile Collaboration, of the book Practices of An Agile Developer I smiled again at the section title “Architects Must Write Code”, but I also wondered, What really is an Architect, what Role do they play and do we really need one ? Luckily, Martin Fowler wrote a piece for the IEEE that answers these questions, at least in terms of Software. The article is here.
In the article there is a quote from an email message between Martin Fowler and Ralph Johnson on the the differences between building architecture and software architecture that in my opinion exemplify what it means to be Agile, and that is, to make (software) it easy to change. The quote and article go on to explain how making something easy to change makes the overall system a little more complex and I’m not in total agreement with this, but the point I want to make is that Agile is about the practices that make it easy to change. Practices like Test Driven Design, Pairing, Continuous Integration, feedback loops (Iterations), and a constant focus on working releasable software.
Agile and it’s practices are why I confidently put off decisions on various components until the last possible minute, which is when we are most likely to know the most about the real needs of the component. So embrace change and make it easy to do it.
What I don’t do, and what I don’t believe Agile advocates, is to leave the gathering of scope until the last minute, since having some idea of where the project is going and what it may be delivering is crucial contextual information. I’m not saying you need to get all the stories up front, but most of the epic stories is a good start.
Now this is neat !
And a new LISP like dialect that targets the Java Virtual Machine called Clojure
A friend of mine has had one of those awkward meetings at his Company where they want to bang a hamster through a star shaped hole and not make a mess, you know the ones. In his case it was on how long his project would be without having all the requirements, fun times for him.
The project is an Agile one so the developers started explaining the Point scheme and how they had a heuristic from the last project that we wanted to use for this one as a starting point. However, the road-block, head against a brick wall came about when his management estimated the “optimum” points for the team and thought their heuristic was too low. He says it went something like this ….
You have 5 developers and an iteration of two weeks, so that is 5 x 10 = 50 points.
He explained that this was totally unrealistic since it didn’t even account for toilet breaks during the working day. His management relaxed the estimate by 40%.
This was still double their established heuristic which he thought they could improve on, but at least their heuristic was a realistic starting point.
Luckily, Fred, a member of his development team piped up with a formula for determining a good starting Point Count for the iterations. It went something like this:
Days in Iteration x Developers in team x Skill Level of Developers x Company Efficiency.
Interestingly this formula resulted in a point count that was higher than his heuristic but one that was lower than “60% of optimum” that was proposed by his management.
The Skill level a developer is a measure of their efficiency when working on the project, while the Company efficiency is a measure of what percentage of time at work the developer is involved in actually developing for the project. For example, he has a regular company meetings and other non-project interruptions which all reduce the time his developers can be working on the project. He quickly noticed how the Company Efficiency and Skill level effected the Point Count dramatically. Here is how his figures looked:
10 x 5 x 70% x 85% = 29.75 Points
He reached an agreement using the formula. Maybe you can use the Point Count as a start and then as each Iteration completed you can use the achieved Points as the goal for the next iteration, which also means you need to use the achieved Points in the Planning games.
My presentation on LISP has been given to the Melbourne Patterns Group, and if there is a big enough interest I will post the slides, however the slides don’t really stand alone as I don’t put what I am saying on slides, I just use them to illustrate my points. Something I learned from Presentation Zen, which I blogged about earlier.
A special thank you to Bill Birch who answered questions on LISP and showed his Genyris dialect of LISP, and to Henry Guillaume for providing me some Emacs LISP code he wrote back in the day, which incidentally is still in Emacs today.
One attendee said: “?first really interesting user group meeting I’ve been to this year”
Today I am giving the same presentation as a brown bag to the developers at work, in the hope that they look further into LISP.