A.K.A. The Version 3.0 Myth. A.K.A. The Rewrite Myth.
I recently overheard a developer telling his manager a variant of what I call “The Version 2.0 Myth”, it went something like this:
If I could write this module again it would be half the size and so much faster… It would be worth doing just to fix all the bugs
Sensibly, his manager didn’t take him up on the this idea; this promise which seems to persist in development circles of a mythical “Version 2.0” that delivers improved efficiency, cleaner code and no bugs.
I’ve also heard it as the Version 3.0 Myth, where Version 1.0 is ugly and buggy, the second version is over-engineered and the 3rd… the 3rd is a masterpiece of software craftsmanship!
Here’s why it’s never so…
We’re regularly told to keep things simple; to produce simple designs, to keep your application “globally simple”, to reduce complexity. But it can often seem as if simplicity is itself a goal, regularly quoted as best practice without explanation. So what should it mean in practice and how can the “simplest solution” be achieved?
I believe the origins of this quest for simplicity lie in Extreme Programming’s (XP) suggestion that we produce “The simplest design that could possibly work” (based on the subjective TUBE qualities of simple code design). It’s great but rather vague advice which is regularly used as a justification for pedestrian solutions, never ending “refactorings” and both naive and, ironically, over complicated designs.
There is an excellent chapter in “Extreme Programming Explained” (Ken Auer, Roy Miller) all about this idea, unfortunately I’ve been unable to find it online but you will certainly not regret buying the book. In it Ken Auer explains:
Simple Design Can Be a Business Decision
And it is this focus on involving the customer that is too often ignored. Here’s an example from a recent project:
Is testing is best done by developers?
Or, put another way, is development best done by testers? Dedicated test teams can hold you back, not by verifying software but by allowing developers to deliver software that does not work.
As we live through the Digital Revolution I see software development in a similar place, professionally, as mechanical engineering was at the turn of the last century. My hope is that soon we will see software engineering attaining the same status as other engineering disciplines so that we can deliver software as respected professionals, but first that will require us to act more professionally.
The way we get such a status will undoubtedly be incrementally and though many iterations – that’s as much what engineering is about as the practical application of learning – but I believe for many software developers the next iteration should be to bring professionalism to their industry.
On my latest Java project, my colleagues and I are keen to improve the readability of test classes. We’ve chosen to use Mockito and Hamcrest because of their natural language approach to mocking and assertions, but on their own they can’t always convey the meaning of values used in a test.
To overcome this, we use a pattern which I’ll call the “Domain Test Values Class”, the purpose of which is to provide values used in the testing of a domain in a way which improves understanding of test code by increasing readability and adding meaning to values.
It’s a two-for-one today – a “gotcha” and a “how to” all rolled into one, this time about redirecting in a Grails filter.
Much like my favicon woes my initial attempt to redirect to a primary domain (a .com without the “www” prefix) had some unexpected consequences when deployed to a live server on CloudFoundry – I started getting warnings that my site had gone down!
In this post I’ll hopefully save you the panic of CloudFoundry telling you that your site’s not responding when you try to rationalise your domain names!
Setting up MySQL connection pooling has been standard stuff in server-side apps for as long as I’ve been writing them, so I was at a loss when, every 5 days or so, my newly deployed app died with this exception:
Exception in thread "main"
Communications link failure
Last packet sent to the server was 0 ms ago.
Here’s a quick gotcha for you. You set up a favicon in the root of your web app, as is the convention, and when you log in you are redirected to a picture of your favicon or you are asked to download it… Weird.
Odds on you’ve installed the Spring Security plugin and forgotten to give permission to the favicon file in the root and the result is that on login Spring Security redirects you to the first restricted item that was requested by the browser – the favicon.
The solution? Easy, set the favicon path to IS_AUTHENTICATED_ANONYMOUSLY in your SecurityConfig.groovy (or database):
controllerAnnotationStaticRules = [
'/favicon.ico' : ['IS_AUTHENTICATED_ANONYMOUSLY'],
I’ve been waiting for the time to give Burt Beckwith’s fantastic UI-Performance plugin a proper post, but it looks like it’s not going to happen any time soon so I thought some of you might find this tip for getting the plugin to cache font files, along with images and css, useful.
The usually simple upgrade process in Grails has caused me a few headaches in moving from 1.2.2 to 1.3.1. I skipped the 1.3 upgrade because there were a few people having issues on the mailing list but yesterday I bit the bullet and encountered a couple of problems.
I think the release notes for Grails 1.3.x have been unusually poor so this post has the issues I’ve encountered in the hope that you won’t go quite as mad as I have. I’ll keep it updated if I find more problems. Continue reading