This article is part of what made me start on trying to organise the Manchester Agile Rails Conference – if you’re interested in it happening please fill in the survey.
You Ain’t Gonna Need It (YAGNI) – vs flexibility
The best software I’ve ever written is the software I didn’t write.
I use Ruby on Rails – you’re probably sick of hearing this by now. But one of the things I really like about it is how much it does for me without getting in the way. If I use the code generators and know what the data model looks like I can generate you a whole CRUD1 application in about 5 minutes, as long as you don’t mind the appearance of the scaffolding application. You can pick other scaffolding or even spend a few minutes changing the generator to suit. There’s another Ruby framework with much less in than Rails called Sinatra 2. It’s very minimalist and you write simple code that returns something to an HTTP request. It’s fast as all hell and very good for writing simple API’s. There’s a very simple application framework called Pandrino 3, that sits on top of Sinatra; it gives a CRUD application with two or three colour-themed looks – and that’s all it gives you.
I can create a working back office system that sits on relatively simple databases in about a day. Yes, a day. I can even put some validation in and make sure your data integrity is properly maintained. There are Python frameworks that do the same.
It won’t be full of flashy JavaScript, or do much beyond letting you edit and maintain your data, but it will do that very well, and cost practically nothing to build if you know your data.
If I use Sinatra inside Rails I can put an authentication layer in by putting it before Sinatra in the application stack using a Ruby gem called Devise 4. It’s about 20 lines of code 5.
I didn’t write any of this code – that’s the point. Some very capable people had a need and met it, they shared it. Then others refined what they had. Then stopped when there was enough to get the job done. They did just enough to let fools like me sit on their coat tails, bless them.
Rails is opinionated – if you do it the ‘Rails way’ then it’s easy to do what you need. If you decide to be another damn NIH 6 geek who has to hand-craft the journey of every electron then go do that. The rest of us are helping people get what they want. The opinions are also those of people who know what they’re doing. So ignore them at your peril.
How much is enough?
In one of my other lives I play blues guitar. I was brought up on (amongst others) Paul Kossoff 7, he’s well known for playing the rather splendid guitar solo on All Right Now, however one of my favourite tracks is Oh I Wept – the guitar solo lasts about 30 seconds and is sublime (the rest of the song’s pretty dull if I’m honest). He’s quoted (somewhere) as saying it’s not the notes you play, it’s the ones you miss out that matter 8. When you listen to that song you know what he meant – probably 20 notes played supremely well, and the right ones to pick up the feeling of the song and raise it from blandness. He was originally a classical guitarist and could probably have played at 100 miles an hour – but didn’t. He played exactly what the song needed, and no more. This requires a kind of sensitivity, of humility, that’s pretty rare.
I’m a developer, I think in code. I like code – complexity and shiny new things fascinate me (at least while I can keep them in my poor old head). When I look at problems I see solutions – when someone talks to me in meetings I’m writing software in my mind (if I’m not playing guitar there). Fred Brooks (I bet you were wondering how long it would take to mention him) said 9 throw the first one away. I’ve done this plenty of times. You look at something that kind of works – and realise you haven’t understood properly. The first attempt is about understanding what the question is, you don’t have an answer yet, the second attempt will be closer – closer, not necessarily right. When I was a couple of years into being a developer I learned a great lesson from Pete Wilson 10 (you there, Pete?), who worked with me on a system for hospitals. We were looking at a vast lump of ‘C’ code built to load data into the accounting system we were working on. 300+ lines of code sat there. We were pairing before there was such an idea, just talking it through – I pointed out that the pointers in this code weren’t used right or something – he agreed and deleted all of it. All of it. Started again. Didn’t try to fix it, deleted it now that he understood the problem. Stopped the cut and paste monster 11 in its tracks.
This shocked me to the core. No fiddling. No clever editor macros to move variables about. Delete it and start again. Wow. Don’t waste time loving that sick puppy, put the poor thing out of its misery. When I pair with people they get scared when I just delete things that are wrong. Sometimes whole methods or classes. But if they’re wrong they’re wrong – get rid of them. You need to ignore the emotional investment in the code and be glad you learned something. The code is a conversation.
Complify and Simplicate
We’re always trying to get to answers as coders – all the time. I watched a talk on Simplicity Archtecture 12 by Dan North. One of the key points that struck me was the tension between YAGNI and flexibility. If you write software that can do anything in the problem space it it very flexible. So, lots of meetings where developers and designers have said but what if a lot and you end up with something that can do just about anything – but then only a small percentage of it is actually used. Anyone who has tried to migrate from Word 2007 to the latest incarnation with the ribbon bar and all the menus moved about will know how this flexibility feels to the user – as in it gets in the way. Most people only use about 5% of anything complex. What use is a retail site where buying stuff is hard because so much attention was paid to SEO that you can’t find the buy button? But you’ve been to that site – I was recently foolish enough to buy some lottery tickets on line – the BUY button is bottom right and very small – what’s the main function of the site? Selling tickets. What’s hard? Buying them! It took a couple of minutes before I could enjoy the vicarious pleasure of maybe winning £33 million for a £2 stake – a couple of minutes that nearly made me give up in frustration. I think they want you to read all the advertising copy about how wonderful they are first and the button sits at the end of it – I just wanted the button.
Other points about flexibility vs YAGNI (or the absence of unnecessary complexity) from Dan’s talk (mixed in with things that occurred to me while I was writing them down):
Ease of change. Maximise the work not done 13 – do nothing yet, defer until the last responsible moment, then make a decision. This is one of the Agile principles and gets forgotten a lot.
Flexibility, on the other hand, is shove everything in just in case. This is expensive and very hard to do. Also pointless. It’s sticking the space shuttle engines on a 747 – madness.
Humans are designed to simplify and generalise what comes to them or they’d be overwhelmed. We get wrong footed by our complex society and the demands of work. One of his colleagues came up with the words complify and simplicate – humans generally try to over complicate things because they see patterns everywhere, even when there aren’t any, and then try to generalise them – hence complify. The goal of complicated endeavour should be to do only what’s needed and no more – simplicate.
Complifying’s most obvious symptom is yak shaving 14 – running off away from the problem because you haven’t taken a step back to think it through properly. Procrastinating without realising it. Dan’s solution to this is to ask why along the lines of the old 5 whys 15 technique.
Simplication – you need to go the other way and take a step back from what’s in front of you. Ask how?
Deliberate discovery – am I tackling the thing I am most ignorant about now? Ignorance is where the risk is. Eliminate oh shit moments at the end of a project. Tackling ignorance also gets rid of fruitless arguments around opinions – get some hard data and go where it takes you.
Every time someone says but what if – say will it? Talk to the user of the software, go for a walk. Use evolution to decide what lives 16: as in ‘no’ is the answer to any new thing until it manages to establish itself.
Dan talks about a technique I’m going to try soon: creating beyond/towards lists, as in go beyond late finance reporting, towards timely information – sometimes towards is too big a jump so create a column in the middle of the list via – this will help you come up with a road map of where you want to go.
He was also scathing about user stories – as in what the user wants, in the end, is capability – I want to be able to do something I couldn’t do before – the old scrum/XP thing of done means done – done is when you have the capability, nothing less than that.
Solutionitis and Cargo Cults
New coders, particularly since the invention of the internet and the ease of copying and pasting, tend to copy things they don’t understand and then poke them with a stick until what they see seems to respond in the right way. In Pragmatic Programmer 17 they call this programming by coincidence (see also Cargo cult programming 18 ). If you were thinking of evolution as a metaphor this might be a valid approach. But as a thoughtful approach to whatever problem you’re trying to solve it’s beyond poor, it’s a waste of time and gives you untestable rubbish instead of crafted code. If you have no idea where to start ask someone. Seriously, ask someone. Ignorance is not a sin, whatever various world religions may say. On the other hand, hiding it is – because it costs time and money.
When I pair with someone I try and stop them writing code. I try and use the framework. I hate repetition because it’s dangerous and expensive. Rails is fast to get started and has a lot of useful stuff to help you. To get the most out of it you need to learn it, and read the books to keep up, and pair with people who know different things from what you know. Once that’s done you can get the framework to do the work for you, and be proud of the code you didn’t write.
But, if I wasn’t writing a database-backed website with some Ajax and dynamic content, Rails (and Ruby) might be totally inappropriate. I still occasionally write ‘C’ code, I still write simple text processing things using Awk – it just works for some kinds of problem. Always starting with the same set of tools, regardless of what you’re doing, is solutionitis. You think you already have half of the problem solved − maybe you don’t, maybe your tools are going to get in the way.
Pareto has two ends
In essence 80% of the results come from 20% of the effort 19. You can have a is the cup half full or half empty kind of argument about this; as in – saying you still need the remaining 80% of the results – so now you need to sit down and get obsessed by details. Or, if you’re looking at something that brings money in to your business you can say – where’s the next 20% I need to do? Most of the time the second question is the one worth asking. If you’re building something that involves human life or safety then you need the other 80% – but that’s part of the cost of safety critical systems and no-one will baulk at paying it, unless they’re an idiot, and then I would get away from them as fast as possible.
Productivity
I was browsing Martin Fowler’s blog the other day and came across this unfortunate truth: you can’t measure productivity 20. But I think you can be far more productive if you don’t write code. Investing the time and energy in understanding the framework you use, and in finding libraries you can trust that do chunks of work for you, is productive. Writing the 20% and no more is productive. All the rest does is make your yak get cold.
YAGNI and real life
So, when someone tells you you can’t do something. When a problem in your life looks like it can’t be solved. When you can’t work out how to do something that isn’t software. What code can you not write? What things don’t you need to do? What yaks don’t need to be bald? It does no harm to apply YAGNI here too.
1 Create, Retrieve, Update, Delete – the four operators of the database apocalypse. http://en.wikipedia.org/wiki/Create,read,update_and_delete
3http://www.padrinorb.com/guides
4https://github.com/plataformatec/devise
5http://pragprog.com/titles/jvrails/crafting-rails-applications last chapter.
6http://en.wikipedia.org/wiki/Not_Invented_Here
7http://en.wikipedia.org/wiki/Paul_Kossoff
8 I suspect a lot of other people have said this too.
9http://en.wikipedia.org/wiki/Mythical_man_month
10 Emigrated to New Zealand in the 90’s and I lost track of him. Last known working for Sequent before IBM bought them.
11 You paste something in that compiles and appears to work – but has the wrong variable names and you forgot to change them, until it’s cost thousands and everyone’s embarrassed. This happens all the time.
12http://www.infoq.com/presentations/Simplicity-Architect
13 Agile manifesto again
14http://en.wiktionary.org/wiki/yak_shaving see the second definition.
15http://en.wikipedia.org/wiki/5_Whys Click through to why/because as well.
16 Rework discusses this in some detail
17 Pragmatic Programmer
18http://en.wikipedia.org/wiki/Cargo_cult_programming
19principle”>http://en.wikipedia.org/wiki/Paretoprinciple
20http://www.martinfowler.com/bliki/CannotMeasureProductivity.html