ConferencesPosted by Andreas Sat, April 19, 2008 08:50:17
Last week it was time for Developer Summit, Cornerstone's annual conference for software developers. I have the feeling that the conference is growing every year, both in terms of size and quality. As a track host - I was filling in for my colleague Jimmy Nilsson who couldn't make it - I only got to see the presentations on Building for the Enterprise the first day. I am a little biased of course, but I think that it was a very solid track. Succeeding with enterprise development requires skills in a number of areas, that was Jimmy's perspective when he put the track together, and it was reflected in the different presentations:
Rickard Öberg was giving an introduction to his latest design effort, the Qi4j framework - the next level AOP, or OO on steroids you could say. As always, Rickard is pushing the limit of design to try to solve everyday design problems as simple as possible. Now, simple is a relative term, and as Rickard pointed out, old ways of thinking can get in the way when starting to work with Qi4j. One of the things I found interesting was that layering was a built-in code/design concept instead of merely a rule documented in the Software Architecture Document.
Jim Webber was talking about Guerilla SOA, a highly entertaining presentation full of interesting and fun reflections on SOA, ESB-solutions, the state of the WS-* stack, and much more. One of the points Jim made was that systems integration is a messy thing; ESBs don't really help supporting cleaner architecture, they just hide the mess. And that we don't have to reach to the vendors to get a good integration platform - it's already there, and has been for a long time: the web. Http and it's supporting infrastructure has a lot to offer, and Jim was giving examples of design patterns to use for http-based SOA scenarios. The room was packed for this presentation, and I don't think anyone regretted coming to listen to Jim.
Johan Andersson from Qondoc System talked about Automated Acceptance Testing and introduced us to the open source testing framework TextTest he has been involved in developing. Implementing effective acceptance testing is a cornerstone in agile development, and the way it's done in TextTest is quite different from what most people are used to. The approach is basically to put log statements in the source code, and to compare these between test runs; as long as they are the same the behavior is unchanged. For this approach to work we need ways to automate tests at the UI-level. Johan showed a couple of different Java Swing-based UI test-drivers and the remarkable difference in readability of the tests. What still bothers me is that there is a lot of manual work in terms of translation/mapping to obtain that readability. Would it be possible to record understandable tests directly from executing code just by naming UI controls in an appropriate manner; or maybe by applying some metadata to them?
Joakim Sundén made his debut as a conference speaker with his talk Professional Ethics in Software Development - and a great debut it was! Joakim's talk would have fitted great in the People matters too track, but I'm really glad we got to get him in this tech-oriented track. Not only did Joakim manage to create a great atmosphere, and give a highly enjoyable talk, he also touched the very essence of what is important to do well in software development: having skilled individuals who care about their work. As Joakim pointed out: The knowledge, techniques, and practices are all out there, but as a community we are not that good at using them. It's always easier to blame someone else for ugly code: I didn't write it; We don't get time to do good design; We never get to learn new practices. But the fact is that you can often solve the problems yourself. Actually, often the ONLY way to make a change is by starting to change yourself. Joakim's blog is a good starting point if you want to find ideas and references for developing your skills.
Christian Weyer finished the track with some leading edge technology: The Internet Service Bus. I've never met Christian before; I suspect he thought I was a little bit dumb when we first met... Christian was supposed to run some demos and had problems with a shaky Internet connection. My response to that - not just once, but a couple of times - was "Can't you run the services locally?". Finally he looked at me and said "No I cannot, it's the Internet Service Bus - you know...". Guess the title of the presentation was a pretty good hint :-) Anyway, the Internet connection worked after all, the demos worked, and the presentation worked! High energy, some leading edge stuff, and a fun presentation from Christian was a great way to finish the day. The Internet Service Bus definitely is an exciting concept; read more on Christians blog or check out this link.
I gave a presentation myself too, called Testing and Refactoring Legacy Code. Using the L word might not seem to be the smartest way to attract listeners - that's what I thought at least. But after my presentation last year - Learning from Legacy - I've realized that there is a big interest in this topic. And it seems to appeal to developers and managers alike. Guess we can't escape reality: most of us work with code-bases that have been around for quite a while. For me, working with and talking about legacy code has become a great way to better understand and explain software design. Gaining insight from studying history and archeology works in the software domain too.
Apart from the Building for the Enterprise track I did not get to see as many presentations as I would have wanted. However, I was fortunate to be able to go listen to Dan North's talk on best practices. I'd been told that Dan stole the show at Öredev last year, and now I understand why. If you missed Dan's presentation you have the chance to catch up by reading his article on the topic.
Thank you Cornerstone for a great conference! I'll hope to be back next year, in one way or the other.
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...
TDDPosted by Andreas Fri, October 19, 2007 11:11:35
Test infected developers often claim TDD to be the most important tool in a programmer's toolbox: "TDD makes you more productive. It drives good design and high quality code. I could never go back to not writing tests again." you hear them say. I am like that: infected. I have raved about TDD for years, believing it to be a revolutionizing approach to programming.
But I've changed my opinion about TDD. Not that I don't like it any less - I still think it's a wonderful tool, and it still helps me learning more about design. I use it all the time, and I am eager to show and give support if someone's interested to learn. However, I have realized that TDD is not the instant quality and productivity injection I though it was. Not for every developer, not for every team. My previous assumptions about TDD were based on a typical case of the syndrome works-for-me-must-be-good. And also, it is easy to forget the struggle you've been through to get where you are today. And learning TDD can be a little bit of a struggle.
I think TDD is great in the same way that agile is great, or object-orientation, or design patterns: great when you know how to use it effectively. When you don't, it may cause more harm than good. TDD is deceptively simple: Red-Green-Refactor, Red-Green-Refactor, ... The basic concepts are easy to understand, it is easy to get started. But when trying to solve real-world programming tasks, many TDD beginners are likely to run into enough problems to get turned off by the TDD concept, and there's an obvious risk that they stop using it. And if they are actually able to finish a task using TDD, the solution might very well be the same kind of tightly coupled, brittle, monolithic (or whatever style) software as used to be the case before using TDD, only with a bunch of tests added to the mess. These are some common problems I have observed:
* Difficulties doing design at the keyboard. Many developers become paralyzed when trying to come up with tests. They are not used to thinking in terms of tests as specifications. They become stressed by proceeding so slowly with the programming compared to what they're used to. They want to do design before starting programming. I think this is an issue for both die-hard TDDers and newbies: Some developers should do more up-front thinking, others should do less.
* Difficulties to decompose a solution into testable parts (and make them fit together). A small number of big classes and methods is the norm for many developers. And often these parts have dependencies on resources that gets in the way and cannot easily be handled when testing.
* Tests become brittle, and have to be rewritten for the smallest code change. This is one of the true challenges for any TDD practitioner: being able to write tests that are not too tightly coupled to the implementation, while still being simple enough to make progress in the Red-Green-Refactor cycle.
* A lot of tests where it is easy to test, but few, or no, tests in important places. A typical example is testing get/set of dumb properties but failing to cover the interesting scenarios that explain the big picture (the specification aspect), and involve more complex behavior where any potential bugs are likely to appear.
* No real refactoring is going on. Two main reasons I think: developers either don't have a feeling for refactoring (neither smells, nor solutions), or refactoring requires tests to be rewritten, which seems like too big a cost.
Frankly, skilled TDDers run into these problems too. The difference is that when they do, they know how to react. And that's the great thing about TDD: it gives you feedback, instantly challenging your design decisions, and on a deeper level the way you do design. Being able to understand this feedback, and knowing how to react appropriately, takes insight and experience. Not only design experience, but also experience of the TDD specific stuff. Is the design seriously flawed, or does it just need small modifications to become testable? Did I try to solve too big a chunk of the problem when I wrote my test, and if so, how can I find an appropriate smaller chunk to work on? And so on...
So, if TDD is so hard, then why use it? Or at least, why try to sell it to less experienced developers? Well, are design patterns too hard to use? Yes! I hear many developers scream. Or objects - yes again? Well, functions then, are they too hard? Or maybe programming as a whole?
In practice, TDD is not that simple. You will not instantly become a great designer just because you start doing TDD. You are constrained by your existing design skills, your talent for spotting smells and come up with remedies, and you're ability to design software that is easy to test. But at the same time, that is why I believe TDD can be such a good tool for developing skills in those areas. It gives you feedback! The only hard prerequisite is your interest in software design, and you're willingness to put in some work to become a better developer. Prepare for a little struggle, prepare for improvement!