I am in London for the QCon event, a vendor-neutral development conference which I have been fortunate to attend regularly over the last few years.
These events tend to have an underlying theme, which reflects the current thinking of developers and software architects. Each year I hear cogent and thoughtful explanations of why this or that approach will enable us to code better and please users more. Each year I also hear cogent and thoughtful explanations of why the fix proposed last year or the year before is actually a prime reason why projects fail.
Way back when it was SOA (Service Oriented Architecture) that was sweeping away the mistakes of the past. Next SOA itself was the mistake of the past and we got REST (Representational State Transfer). This year I am hearing how RPC is making a comeback, or at least not going away, for example because it can be more efficient when you want to transfer as little data as possible across the WAN.
Another example is enterprise Java. Enterprise Java Beans and J2EE were the fix, and then the problem, for scalable distributed applications. Rod Johnson came up with Spring, the lightweight alternative. Now I am hearing how Spring has become bloated and complicated and developers are looking for lightweight alternatives.
Test-driven development (TDD) brings fantastic benefits to software development, making it possible to change and improve your code while defending against the introduction of bugs. Yesterday though Dan North observed that TDD also has a cost, in that you write much more code. It is not uncommon for projects to have more test code than code that is active in production. If you did not write that code, you could be doing other productive work in the time made available.
Agile methodologies like Scrum were devised to promote or even create communication and agility in software teams. Now every big enterprise vendor says it does Scrum and runs courses, but the result is a long way from the agile (with a small a) original concept.
This year I have heard a lot about over-optimisation, or creating code for situations that in fact never arise. This is the problem to which the solution is YAGNI (You Ain’t Gonna Need It). Since they apply across all the methodologies, I suggest that YAGNI, and its cousin DRY (Don’t Repeat Yourself), and the even older KISS (Keep It Simple Stupid) are the most enduring software methodologies.
That said, even DRY took a beating yesterday. Greg Young in his evening keynote said that rigorous DRY advocates can end up creating single blocks of code where really the procedure was only nearly the same. If your DRY functions are full of edge cases and special conditions, then maybe DRY has been taken to excess.
In the light of the above, I would therefore like to propose the first draft of my first theorem of software development:
There is no development methodology which will not become a burden when embraced rigidly
The other lesson I have learned from multiple QCons is that effective teams and smart developers count for much, much more than any specific tool or language or approach. There is no substitute.
Amen to those sentiments. I think that when developers get to a certain level of maturity that it’s a real mistake to start to impose standards and methodologies upon them from above. I also find that system architects are probably the worst people for doing this in that they delight in telling devlopers how not to go about solving problems.
Nice theorem!
Something more radical, half tongue-in-cheek: if there’s no better name than “methodology” for something, don’t do it!
I like to turn the standard DRY argument on its head. With DRY you don’t have to add a bug to each and every file – you just create the bug once in a common function and it’s implemented everywhere with minimal effort.
Amen. I’ve always liked Process is no substitute for synaptic activity. Process can be swapped out for Frameworks, Best Practices, Tools, etc and it still holds true.
A droll analysis. As a co-attendee of QCon, I’d say Greg Young was merely a releaser of squibs for effect. Any technique can be over-applied in theory; but I have yet to see this happen to DRY. AND he insisted on pronouncing Java ‘Yava’ – what was that all about? Irritated red touch on exit iPhone from me, doubtless swamped by approving green.
A trend I have noticed among people demoing code techniques at this conference: how many are using a Windows machine to do the development? Answer, IME, so far, none at all – Macs all. This attending JavaScript-oriented talks, so theoretically no reason not to use Windows.
Microsoft is almost invisible here, even more so than in previous years.
So which sessions got a green from you Will?
Tim
The stuff that really floated my boat was the functional programming stream. Did you see the Guardian website’s Graham Tackley on Friday explain how they had switched from Java to Scala, with the result that they discovered that they stopped writing tons of grotty boilerplate, and instead were producing pithy, readable code that did the job? Fascinating, especially in teh context of a programming project with which one is familiar as a consumer.
I also really enjoyed the Erlang lectures. Of course it was nice to hear inventor Joe Armstrong making his case, and ditto Damien Katz the CouchDB guy (CouchDB is written in Erlang); but the most striking advocacy – because unexpected – came from Jasper Richter-Reichhelm. He is a programmer for one of those companies that produce those vile (his description) FaceBook Flash games.
The front end Flash part, he said, was of no particular interest. The interesting part was the back end. Here you need to keep your games app server up 24/7, it needs to be fast and be able to scale hugely. He described how, over the course of four game projects, they moved from PHP + MySQL (I think) to Ruby + MySQL, to Ruby + Redis (a memory database) to Erlang. Erlang brilliant (he said) with very many advantages: in-place code upgrade, faster than Ruby, CPU bound (it’s very good at exploiting multi-core), transactional logic for free with the programming model. Problem was: recruitment. Too few programmers know how to use it. So for their next game, they kept the transactional core and base architecture in Erlang, and pushed the games logic out into Ruby. All most interesting.
In both cases – The Guardian and Wooga – it was very striking that the speakers were enjoying their programming, and were proud of what they had achieved. I’m off to get out my Joe Armstrong book and take another run at Erlang to see if I can’t crack it!
Thanks Will. Yes, I loved Tackley’s session and have a post coming I hope. Didn’t make the Erlang ones sadly.
Tim
Real software development concepts: composability, referential transparency (or at least separate pure from impure code). Everything else is secondary and material for sensationalist programmer wannabes like Greg Young.
Mac vs Windows is completely irrelevant for software development, and the fact that you even mention it brings out to light your lack of general knowledge. Read Wadler’s papers; contrary to the general belief that academia lives in an ivory tower, they’re the ones that build upon no-nonsense concepts instead of chasing the latest RoR version just because it’s ‘cool’. That’s the *real stuff*.