People & ProcessPosted by Andreas Sat, March 01, 2008 09:37:35
Java forum the other day was a lot of fun. Actually, the whole day was packed with high caliber geek stuff and many interesting and fun discussions. It often turns out that way hanging out with my colleague Niclas Nilsson. Niclas had planned to meet up with Hans Brattberg and Henrik Kniberg from Crisp, which raised the geek factor considerably. Henrik, the man behind Scrum and XP from the trenches, was going to give a talk at Java forum Göteborg - 10 ways to screw up with Scrum and XP - later in the evening. It turned out to be a really good one!
Henrik's talk was touching many of the typical problems he'd been encountering in Scrum and XP projects. My favorite part was the discussion on Technical Debt; Henrik made the point very well. Being able to explain technical things like this so that stakeholders understand is of extreme importance to succeed with agile. Or actually, to succeed with software development. Check out Steve McConnell's blog post on this topic.
The second highlight of the evening was Pär Sikö's introduction to JavaFX. To tell you the truth my interest in JavaFX was not that big. Pär's highly entertaining presentation changed that quite a bit. Not that graphics/UI programming or animations are any of my specialties, it was more the architecture that attracted me; an architecture where the language was an important part. I don't know if JavaFX is a threat to Flash, or if it's better or as good as Silverlight. But I must say that the approach to put a special-purpose language layer on top of an existing technology stack - Java/Swing - to make it simpler and at the same time more powerful was very appealing.
For example the bind keyword, which associated a variable with another variable or a function, so that changes to the source variable automatically updated the other variable. In normal Java code this would require some kind of observer/observable design, which would add considerable levels of noise to a conceptually very simple intention. And then there were triggers and thread handling built into the language. JavaFX seems to be a good example of how simplifying and constraining a platform makes it much more powerful and approachable to a broader audience. I doubt that's enough for success, or if I'll be part of that audience, but it was cool anyhow.
And the evening went on with more discussions, everything from programming languages, the value of EJB and RDBMSs, and UI design to iterative vs incremental development, team coaching, and broken software process metaphors. And not the least: some wise words from Bruce Lee. Some days being a geek is not that bad at all!
People & ProcessPosted by Andreas Thu, February 14, 2008 09:38:38
In a recent blog post Martin Fowler writes about developer talent & productivity. Fowler's post is centered around a hypothesis that there are developers that are twice as productive as the average developer. The factor 2 is not the important thing here, it's not a universal constant or so. It is simply a number that fits well in the example Fowler is using. The conclusion is that due to the costs of communication overhead that comes with a bigger team, paying twice as much for individual developers that are twice as productive is a wise thing to do. Fowler also mentions the positive effects on the code-base that comes with more talented developers. He doesn't go very deep into this area, which gives me room to elaborate.
First, it is important to understand that developer talent does not just mean "extra speed". A talented developer will not produce the same solutions as the average developer, but something better. In many cases this better solution can never be reached without a certain amount of talent. At the extreme, there are solutions that simply cannot be reached without a very high amount of talent; substituting talent with manpower is not an option.
At the opposite extreme we have tasks where the talented developer will produce roughly the same quality as the average developer, only faster. It is important to understand that this types of tasks are very uncommon - or at least they should be. If the output of a development task is so well-defined that any two developers will end up with exactly the same code, the work should probably be automated in the first place. Which brings me to the next aspect of individual talent: making other developers more productive.
Looking at productivity only from an individual perspective is a mistake. What matters is team productivity. And this is where it starts to get interesting. Individual developer talent has the potential to boost the productivity of the whole team. For example, talented developers have the capability to develop frameworks and tools, which can boost productivity and software quality a lot. I often hear that framework and tool development should not be part of a typical application development effort. The truth is that there is always needs and room for this kind of development. But sometimes it requires skills that can not be found on the team. And when frameworks are developed without the right level of talent, we're better off without them. Also, it is a big difference between generic frameworks developed to be used by others, and small application specific frameworks, which are really just the result of the need to remove duplicate code in an application. In my experience a majority of development projects would benefit from more custom tools and frameworks; in such cases, paying for the proper amount of individual talent is money very well spent.
Better team scalability + more agile teams + better code-bases + pulling off demanding development tasks + making others more productive. To me this is compelling. Still there is a lot of hesitation to pay more for talent. Many (most?) people/organizations don't seem to be convinced. Some are though; I recently stumbled over XML People where Tim Bray writes:
"People in the trade will tell you that a good programmer isn’t twice as good as an average one, but many times as good. There’s no meter to measure such things, but I’ve worked for, and with, and managed, a lot of them, and my experience is that the performance of working programmers varies by a factor of at least 100."
Food for thoughts...