Frank Carver's musings about software and life
This article really resonated with me. Some of the most successful projects I have ever worked on have been inspired by a single visionary, then worked on by an empowered and collaborating team to bring into existence.
Read more at Pragmatic Agilist: Agoraphobia Meets Individual Genius.
I have spent many years developing web applications in Java for corporate clients. During that time I have used a wide range of frameworks, APIs and other useful stuff. I have written my own versions (sometimes several) of many of these components, learned the tools well, and become very productive and effective.
However, it has been almost impossible to take that expertise, hard work, and custom code and easily/cheaply turn it into usable web applications for general public use. Low-cost hosting providers have generally shunned Java support. The most reasonable one I have found is LunarPages who actually support both ad-hoc JSP and deployment of custom web applications as war files, even though you have to search pretty deep in their web site to find out, and pay an extra dollar or two a month for the privilege.
So for my own projects I have been looking for an alternative for a long time. A way of developing and testing web apps on my various development boxes (currently running Ubuntu, MacOS X and Windows XP) and easily deploying to a low-cost hosting provider.
By far the most popular web development language is PHP. It’s available pretty much everywhere. It’s so focussed on web app development that the primary unit of coding is the web page. Believe me, I have tried to like PHP, but it’s just so clumsy. After a few paces the application begins to get tangled, development speed drops, and bugs creep in. Its web focus makes it tricky to unit test, and end-to-end testing seems to require a full-fat HTTP server. Not for me.
Beyond the traditional stomping ground of PHP, perl, and other CGI fodder is the new range of “trendy” languages. Ruby, Python, Erlang and even the venerable smalltalk are trying to position themselves as the thinking-person’s web development tool.
Erlang syntax is a bit too odd for me right now, although I may come back to it later. Smalltalk is interesting, but carries with it so much history and is hardly a popular choice for low-cost hosting providers. That leaves a short-list of Python and Ruby.
As languages I like both Python and Ruby. They have broadly similar design goals, both have keen developer communities with plenty of open source resources, and both are commonly found on linux-based web hosts. In order to decide between them I took a look around their frameworks and APIs.
Python has Google on its side. It’s the “native language” of the hugely-scalable Google AppEngine. However, a scan around the web looking for ways of writing web applications led largely to two: Zope and Django. (for balance, there are plenty of others, but these are the standout examples). Zope is old and sprawling. It has some great ideas but is hardly an obvious choice for small, tactical web apps. Django is a bit lighter, but still seems to assume a lot and require a lot of relatively fiddly config.
In the Ruby world the blindingly obvious choice for a web application framework is Rails. Sometimes it seems as if “Ruby” is just another way of saying “Rails”. However Rails, like Django, assumes a lot about the eventual application. Rails also makes a lot of use of code generation, which I simply do not like. I would always prefer that a framework eliminate boilerplate rather than just generate it for me. Looking a little further beyond Rails I came across some really interesting alternatives, and the one which really sparked my interest is Sinatra. For me this one framework made the difference. It’s so streamlined that a basic web app is as simple as:
require ‘sinatra’
get ‘/’ do
‘Hello world!’
end
Best of all, simply running the above file using ruby hello.rb starts up a web server and begins serving pages on port 4567. No extra config or faffing.
Looking around for low cost hosting I found that the provider I already use (Dreamhost) supports Ruby web hosting using Passenger. An ssh to the Dreamhost server for “gem install sinatra” followed by a little bit of FTP and my first Ruby/Sinatra application was live!
A key part of any web application is the pages, and a key part of generating pages is a good template language. As a general-purpose templating language, I still prefer my own Stringtree Templater, part of the Mojasef Java framework. So far I have not found a similar templating solution for any other language. However, for the limited and specific requirement of generating web pages, I am becoming quite fond of Haml. It’s not at all a general templating solution, but it does massively simplify the generation of web pages.
Finally, after years of CVS and Subversion, I have made the jump to distributed version control. Not only is it more trendy, but the ability to work on multiple code branches, on multiple machines, with or without an internet connection, and easily share, identify and merge when necessary has been a key benefit. Occasionally I wonder if one of the other distributed VCS (Mercurial, Bazaar, darcs, etc.) would have been a better choice, but I needed to settle on one and get to grips with it. So I chose git.
There have been a few speed-bumps. Attempting to learn git from manual entries and simplistic tutorials gives very little help on deciding what is worth doing. After about a week of following the techniques in A Git Workflow for Agile Teams, though, I began to get comfortable. Add to that some lovely web deployment tricks from A web-focused Git workflow and a selection of GUI tools ( Git Cola, GitX, and Git GUI ) to get round all that tedious “git add” stuff and simplify infrequent operations, and git becomes a very useful and productive tool.
The upshot is that I currently feel very productive.
My toolbox has a few other things in it, but they are still candidates for change if I find anything better. I am managing my projects and git repositories using Unfuddle but it has a few shortcomings including a ticket system which is a pale and clumsy cousin of bugzilla. For editing I use generic syntax-highlighting text editors (gedit on Linux, TextEdit on Windows and Smultron on Mac) but none of them have the nice autocompletion and refactoring tools I grew addicted to in Eclipse. Suggestions welcome!
Finally, a few spare links relating to the tools mentioned above.
Sinatra: 29 Links and Resources For A Quicker, Easier Way to Build Webapps
I have seen several attempts to implement an agile approach to software development within large organizations, and in many (if not all) of those cases the end result has not been very compelling. This is in direct contrast to agile adoption in smaller, typically single-team, companies.
It’s natural enough to assume that problems with implementing agile processes in large organizations stem from some characteristic of the organizations themselves. Amr Elssamadisy, however, has a different suggestion. Perhaps some of the problems stem from the use of external agile “coaches”, and the way that they affect the way both the agile team and the organization operates simply by being there.
Read more at: InfoQ: Opinion: Agile Coaches Frequently a Source of Adoption Problems.
… if they involve pancakes and beer!
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”.
I have just listened to an excellent podcast interview with Andy Singleton from Assembla in which the discussion ranges around his extreme views on how to run highly productive distributed software teams.
Top tips include “don’t interview when hiring”, “don’t estimate work”, “don’t do conference calls”, etc… Contentious, but very well explained and justified. This podcast is so packed with thoughtful stuff that I’m sure I’ll listen to it again.
Coping with difficult times is a topic of the moment. Jared from Agile Artisans writes about optimising a team.
A hot topic in software development circles at the moment is the interaction and demarcation between “developers” and “testers”. Development uses an agile approach but it’s sometimes hard to see how this sits with the testing folks, particularly as most stories seem to move snappily through development then pile up in testing. Sometimes it seems as if a team needs more testers. Sometimes it seems as if a team should reduce or dispense with testers altogether. Sometimes it seems as if roles and responsibilities should change completely.
I wish I knew an answer to this, but at least it is encouraging that others are also considering and writing about these issues.
InfoQ: The Correct Ratio of Agile Testers to Developers? It Depends.
InfoQ have published an article which offers a compelling argument that common corporate performance reviews are fundamentally broken, and should be abandoned. While I largely agree with this premise, I don’t see a great deal of improvement in the proposed solutions.
Perhaps it reflects differences in the kinds of places we have worked, but for me an effective performance review should concentrate on a holistic view of how the individual has contributed to the success of the organization. I am worried that neither of the two proposals encourages “thinking outside the box” and doing whatever is most effective for the business. Instead, they concentrate on reinforcing existing decisions such as pigeon-holing staff into “team members” and “managers”.
Team composition and team dynamics are fascinating me right now. We are trying to grow an effective development team, and encourage a process where both the team as a whole and the individuals are doing their best for the company, the product, the customers and them selves. Linda Rising has some thoughts about some of the things that can perturb this effort.
InfoQ: Interview: Linda Rising: Prejudices Can Alter Team Work
To make software development work, everyone involved needs a good working knowledge of the product, the domain, the solution and so on. Communicating enough, but not too much, information can be tricky, especially in an agile environment where anything can change at any time.
Tarek Abdelmaguid has an interesting list of ways to communicate while working on a project. I have done almost all of them with various clients and employers, and also made a lot of use of instant messaging. There is definitely scope for using more structured communications such as mailing lists, internal blogs and forums, though.
On Programming and Applications Development: Project Development Knowledge: Sharing and Enduring
I started to idly watch this video presentation, but quickly found that it describes a situation eerily close to our own, so I have decided to set some time aside to watch it in proper detail. I hope it pays off!
I’m definitely enjoying reading Mark Needham’s blog. Today it included an interesting article discussing productivity among individuals, pairs and teams.
Team Productivity vs Individual Productivity at Mark Needham
A nice article about the potential benefits of colocated working.
AGILE IN ACTION: Why would I want to sit with that bunch of nutters?
An interesting article, apparently based largely on the keynote from Agile 2008. Some clever stuff about estimation, averages, and the wisdom of crowds in the context of software development teams.
I’ve never worked on a team with an explicit Agile Coach – I know several people who have worked in that role, just never with me.
With that in mind, this article is an interesting exploration of what the role of “agile coach” actually entails.
I’ve certainly seen this in action. Confusion between the idea of a team, and the practice of a bunch of people “working together”. They are quite different things.
can’t argue with this. The particularly important point is that the benefits of co-location are so valuable that they should justify a surprisingly high level of cost. Many employers seem to assume that co-location is only worthwhile if it is virtually free.
This article certainly echoes some things which I have observed. It’s hard to gain the full power of an agile approach, if the agile teams don’t have the ability to address issues across the whole solution. However tempting it may seem to solve the problem of team size by splitting teams across architectural boundaries, this is rarely a good way to solve big problems in a smart way.
Splitting teams by task or feature, and letting each team solve their task or feature in a way which is optimal in the context of the whole system, will almost always result in a more effective solution, and often a solution which is actually much simpler/cheaper than the way it might have been achieved if each team only considered one part of the system.
InfoQ: Choose Feature Teams over Component Teams for Agility
All teams have their ups and downs, and sometimes it seems as if a team would just be better without a particular person. A recent article from InfoQ discusses this situation in the context of the Survivor TV show, popular in the USA, where contestants repeatedly get the opportunity to “vote someone off the island”.
InfoQ: Voting Someone Off the Island on an Agile Team
While I can see that in some situations the ability of a team to decide together that it’s just not working for some team member is useful and valuable. However, I can’t help worrying that there is a hidden dark-side to this.
As well as making rational consensual decisions, groups also exhibit other, less desirable, characteristics. It’s easy to imagine someone being “voted off” because their ideas challenge the status quo, because they threaten the complacent assumptions of the rest of team, or simply because they are different.
A mob, even a small mob, can be a dangerous thing. “Reality TV” such as the above-mentioned Survivor, Big Brother, The Weakest Link, and many more have shown us this again and again. Do we really want to encourage the mentality of conspiring to “vote off” the most challenging competitors in software development?