Assume we’ve got a namespace of Customer and in that a controller for Organisations.

This doesn’t work

class Customer::OrganisationsController < ApplicationController

  respond_to :html 

  def update
    @organisation = Organisation.find(params[:id])
    @organisation.update_attributes(params[:organisation])
    respond_with [:customer,@organisation]
  end

end

It redirects to the customer_organisation show method without checking for errors. I think it should work, but the respond_with code doesn’t handle it properly. Instead, try this:

class Customer::OrganisationsController < ApplicationController

  respond_to :html 

  def update
    @organisation = Organisation.find(params[:id])
    @organisation.update_attributes(params[:organisation])
    respond_with @organisation, :location => customer_organisation_url(@organisation)
  end

end

I’m not sure it’s annoying enough to want to patch it. There are a lot of edge cases in Rails in general around name spaces. Also, note it’s not just update that needs this but also create.

Imported Comments:

malclocke

respond_with :customer, @organisation should work, without the square brackets

Total responents 40

This is a temporary home for this while the main site is built.

Would you attend an Agile Charity Day (there will be a Ruby one anyway)?

Would you prefer a one or two day conference?

Would you like to be on a panel for a balloon debate?

Would you attend a post conference Ruby or Agile Dojo?

Would you or your company be interested in sponsoring Magrails?

Would you like to help with the organisation of the conference?

What Agile topics would you like to see and discuss?

What Agile topics would you like to see that weren’t in the list?

• agile v fragile – when to say no. It’s a fine line between being flexible and being stressed and overworked with constantly shifting directions or new features.
• How to start off
• Estimation
• CEO ACME org. Take 2 Agile pills a day for 6months. SWOT for the CEO.

What Ruby/Rails topics would you like to see and discuss?

What Ruby topics would you like to see that weren’t in the list?

• Building cross-platform mobile applications with Ruby – introduction to Rhodes
• Better Rails application design
• transition to rails 3 – routes
• bundler
• unobtrusive js
• Ruby 1.9 v 1.8
• which editor – textmate, vim, eclipse… maybe textmate etc. hints and tips
• improving productivity (I use textmate but I’m sure I’m not using a tenth of what it can do for me)
• Setting up an agile rails project – the plugins
• test frameworks etc you should use (ie do it at the start cos retrofitting things like cucumber etc is painful)
• Rails deployment strategies – phusion v mongrel etc. (I use passenger as it comes on a single box but there must be better ways)
• Event Machine – writing truly evented systems
• Making stuff work quickly with quality.

Suggested Balloon Debate topics

What Balloon debate topics would you like to see that weren’t in the list?

• IDEs make you dumb
• what’s really happening under the hood
• Cucumber’s wonderful, really

Once

A star died

Made the things bones are made of

All changes

Little star

My teeth

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 CRUD¹ 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 ². 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 ³, 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 ⁴. It’s about 20 lines of code ⁵. 

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 ⁶ 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 ⁷, 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 ⁸. 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 ⁹ 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 ¹⁰ (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 ¹¹ 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 ¹² 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 ¹³ – 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 ¹⁴ – 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 ¹⁵ 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 ¹⁶: 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 ¹⁷ they call this programming by coincidence (see also Cargo cult programming ¹⁸ ). 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 ¹⁹. 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 ²⁰. 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.

¹ Create, Retrieve, Update, Delete – the four operators of the database apocalypse. http://en.wikipedia.org/wiki/Create,read,update_and_delete

²http://www.sinatrarb.com/

³http://www.padrinorb.com/guides

⁴https://github.com/plataformatec/devise

⁵http://pragprog.com/titles/jvrails/crafting-rails-applications last chapter.

⁶http://en.wikipedia.org/wiki/Not_Invented_Here

⁷http://en.wikipedia.org/wiki/Paul_Kossoff

⁸ I suspect a lot of other people have said this too.

⁹http://en.wikipedia.org/wiki/Mythical_man_month

¹⁰ Emigrated to New Zealand in the 90’s and I lost track of him. Last known working for Sequent before IBM bought them.

¹¹ 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.

¹²http://www.infoq.com/presentations/Simplicity-Architect

¹³ Agile manifesto again

¹⁴http://en.wiktionary.org/wiki/yak_shaving see the second definition.

¹⁵http://en.wikipedia.org/wiki/5_Whys Click through to why/because as well.

¹⁶ Rework discusses this in some detail

¹⁷ Pragmatic Programmer

¹⁸http://en.wikipedia.org/wiki/Cargo_cult_programming

¹⁹principle”>http://en.wikipedia.org/wiki/Paretoprinciple

²⁰http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

This is a reworking of a list I created a couple of years ago for a client. Hope you find it useful.

Contents

• Object-orientation
• Dry and Shy
• Tell don’t ask
• The law of Demeter
• Object Composition
• Ruby considerations
• Replace case statements with behaviour
• Fat model thin controller
• Short methods and classes
• General points
• Magic Numbers
• Let Boolean be Boolean
• No Surprises
• Comments
• Exceptions
• Databases
• Filters
• Generic Database Code
• Don’t ‘select *’ from tables
• HTML and CSS
• Javascript
• Recommendations for fixing “unstable” code
• Continuous Testing

Object-orientation

DRY & Shy

Don’t repeat yourself (DRY)

An example of this is having setup and teardown code repeated in every method. This avoids a heavy maintenance load and ensures that the “cut and paste monster” does not create code that looks correct but references incorrect variables, or require fixes to be applied across many classes where they might not be implemented properly.

Don’t tell people about yourself (shy)

In object-oriented design this means that an object should not expose how it does things, it may expose a method that gives you a result saying that it did it. Outside of a class used to transport data around most classes should not expose their internal attributes to client classes.

Back to top

Tell don’t ask

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp

Objects should be told what to do – not asked about their state and then the client object decides, procedural code uses state like this. This causes strong coupling between objects and makes testing and refactoring a nightmare. This also avoids the “train wreck” scenario where you end up with long strings of method calls, e.g.

project.client.calls.first.message

See the following links for more discussion on this:

Tell don’t ask

Mock objects and tell don’t ask

Back to top

The law of Demeter

This came out of a project on object-oriented design called Demeter, it is a more formal way of talking about tell don’t ask. It is also described as the principle of least knowledge. A caricature of this is to say that there should never be more than one ‘.’ in the string of method calls; of course common sense says this is a guideline rather than a hard and fast approach. In essence constructing helper methods to mask out long chains and make it clear what you are doing.

In summary:

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

1. itself
2. M’s parameters
3. any objects created/instantiated within M
4. O’s direct component objects

It is explained here

A common mistake is discussed here; one should endeavour to delegate behaviour not attributes

Back to top

Object Composition

It is often better to compose an object from others rather than extending something and giving it too much to do or overriding the default constructor and creating a hybrid object in a non-standard way.

Ruby-specific considerations

Reusability in Ruby is not just through inheritance. It also works through modules. You need to think hard about using modules or inheritance and be able to justify why you chose one over the other. There are no right answers but don’t just blindly do what you did last time. Sometimes modules can be hard to understand and debug, and even hard to find if they’re in, say, a library directory outside of the main code base.

Back to top

Replace case statement with behaviour

Long case statements are not true object code. Depending upon the circumstances there are several ways to refactor this:

1. Use a Hash
2. If an object needs to be instantiated or a method called then use the technique in 1 to call a lambda function (created using create_function if you’re a PHP head) that will return the object.
3. Any long list, e.g. of return codes, should be held as a Hash and used to return the associated value directly.

A long case statement indicates the target object is not broken up into grouped behaviours correctly – the client object should be calling a method to do what it needs directly and the case statements would be unnecessary.

Testing code written this way is far easier. The dispatching array needs to be set up correctly and each single method can be tested independently. Testing a large case statement is almost impossible. The behaviour in each case needs to be put into its own method.

Back to top

Fat models, thin controllers in MVC

When using the Model/View/Controller architecture any complex work should be done by the model code. This encourages reuse and moves the controller to just controlling and dispatching.

Back to top

Short methods and classes

Methods should not be in excess of about 25 lines including comments. A class should have its responsibilities well-defined and not have more than ten or so methods.

Back to top

General points

Magic numbers

There should be no references to numbers or stages that aren’t given symbolic names to make the code clear. This also means method names, e.g. fred_12321 is not helpful.

Back to top

Let boolean be boolean

Consider the following

isMyNumber = (defined?(biff) && boff == 3) ? true : false;

There is no point in testing a boolean result to return a boolean. (I also have a personal dislike of the ternary operator, because it encourages this kind of sloppiness, think!).

Back to top

No surprises

If there is an accepted way of doing something, e.g. a class constructor calls the super class method, do not create non-standard ways of doing things. If something has to be done in a non-standard way there must be a comment to that effect.

Back to top

Meaningful comments

An example of a meaningless comment is:

-- Open cursor
open cursor x for ...

A comment that just says what the code is doing is a waste of time.

Another example is:

/**
 * Enter description here...
*/

Enter the description or remove the comment. I don’t care if your code generator puts it in, it’s garbage.

Back to top

Exceptions

try{
 someDodgyOperation() ;
} catch( e Exception ){
  return null ;
}

Just don’t, ok? Handle the exception, or at least log it somewhere to give the next poor soul a chance of finding where the problem is. In Java you’ll get a null pointer exception somewhere probably completely unrelated to where the problem actually is, same in Ruby or any language you care to name that has exceptions, just don’t do this.

Back to top

Databases

No filtering of result sets from the database

This involves getting the database to do the work – there should be no need to filter result sets. Retrieving more data than needed has several deleterious effects:

1. Data sets need to be passed through several layers to get to the calling module – the less data that needs to be marshalled and transmitted the better.
2. Retrieving large sets and filtering for a few records can easily cause locking and contention problems.
3. Testing may be difficult because the PHP instance may run out of memory if the sets are not released quickly enough to be garbage collected.

In essence: make sure the database returns as little as possible and keys and relationships are properly policed.

Back to top

Generic database code

If the where clause changes but the columns selected do not, the where clause should be made into a something that can be set. This reuses the method and the return bindings, meaning they only have to be changed in one place

Back to top

Do not ‘select *’ from tables

Under no circumstances should * be selected from a table:

1. All of the columns will be selected regardless of the need for them – see the discussion in in the above section about this.
2. The values returned are dependent on the default order the columns appear in in the database and that is a function of how they were created. There is no guarantee that, for operational reasons, columns in your development and production environments were created in the same order, an RFC could have been applied in a different order – this will break and be very hard to debug.

Ruby on Rails Active Record fixes the ordering problem. But if you have several K of text you don’t use often, it won’t hurt to think about not retrieving it.

Back to top

HTML and CSS

HTML code should not use deprecated tag attributes, e.g. bgcolor, or valign. Styling should be done through CSS.

Sizes of elements, e.g. tables, should be done through CSS also. This allows a DRY approach to styling output.

CSS should not be in line but in its own sheets to promote reusablility and allow the web browser to cache it. It also allows restyling work to be done with a minimum of fuss.

HTML should be conforming, e.g. attributes should be inside double or single quotes and lower case as recommended by the W3C

HTML 5 may change the definition of conforming HTML, because there’s a lot less nonsense in there.

JavaScript

JavaScript should be in separate files, if it needs PHP then the web server will sort this out. If the script is less than twenty lines or so then inline is fine, otherwise it should be handled in its own file. This is to promote reusability of the scripts and allow the web browser the chance to cache the JavaScript.

Most of the comments about code in the above section also apply to Javascript.

Back to top

Recommendations for fixing “unstable” code

In order to change code you must be able to say that your changes have not broken any existing assumptions. This means that you need a reasonably complete test suite to begin with.

Creating such a test suite, and the culture that keeps it up to date, is a sound investment in future. When bugs are encountered then a new test should be created that exposes this error – then it is fixed. The whole suite running ensures that no new bugs have been introduced.

There is a good article (and book) explaining this in more depth

Back to top

Continuous testing

This does not require a large amount of resources and can be built up over time. It needs to be in place before any refactoring takes place. Normal practice is to keep the testing running and ensure that refactoring has not broken any existing functionality.

Deploys are automated and run the test suite against a test database before they happen. Any failure will stop deployment. (in my dreams)

Back to top

Linchpin: Are You Indispensable? by Seth Godin
My rating: 5 of 5 stars
Seriously, if you want to know why your children’s school seems to not be teaching them to think, if you want to know why you hate your job, read this book.
Our entire education system is built around creating good factory workers, who have no initiative and do what they’re told. You may sit in a call centre or push numbers into a computer all day – but it’s still a factory, think about it. Guess what – the factories are all gone or on their way, and cost-cutting means that you can’t compete with folk from other countries. The race to the cheapest is one you can’t win. The race to the most useful, caring, innovative – well, you’re competing with the cheapest, they’re going to lose.
Enter the linchpin – someone who adds value, who cares about doing a good job, who thinks about how to get things done more quickly and to a higher standard, a game changer. Your boss will employ a competent drone if no-one else is available, but would prefer a linchpin. Someone who is difficult to replace. If you don’t want to be easy to replace then read this book and follow Seth’s advice.
The latter half of the book gives a whistle-stop tour of the human brain and goes into some detail about how the “lizard brain” tends to sabotage the thinking brain and choose short term comfort over long term success. It needs to be tricked to get out of the way and allow you to succeed. Godin talks about how the lizard brain made him stop writing the book several times, because it was hard work. The paradox is the lizard brain likes comfort, but is scared of success.
Read this book if you want to escape the whole post-industrial “my job went to India” fear and find your way to a future where you enjoy what you do.
Just read it, it’s the 21st century equivalent to How to Win Friends & Influence People, (which you should read as well).

View all my reviews

Imported Comments:

ChuckJHardy

Reading this at the moment – really enjoying it, thanks for the review

The Circle of Innovation: You Can’t Shrink Your Way to Greatness by Tom Peters
My rating: 5 of 5 stars
Had this book on tape and listened to it many times back in the early noughties. I was writing a blog post about “The Agile Heart” (http://goo.gl/aBCae) and quoted from it, so I got a second-hand copy from Amazon to verify the quote, my tape player having gone the way of all flesh a while ago. Still need to change the quote, but there you go.

Thing is, even now, nearly 15 years after it was first published, it’s a gem. The style is designed to look like his presentations, with a slide-like set of images setting up a proposition and then some discussion about the ideas. I’ve also been reading Linchpin: Are You Indispensable? and they cover a lot of similar ground. Peters’ take is more based on subverting the traditional workplace, “brand you”, “making everything a project”, “making where you work into a company in its own right”. Godin talks about the kinds of behaviour and attitude you need to make what Peters talks about become a reality. The two books complement each other. I think Linchpin is an essential read for anyone who cares about where we are today, but Peters’ book gives some historical context.

The subtitle you can’t shrink your way to greatness is a polemic with the late 90’s obsession with the bottom line: how big corporations were doing a slash and burn on their workforce and their working conditions to drive profit up. But if you race to the bottom you end up competing with people who are much poorer than you are and will do the same low-value work for less in a different country. You lose, the whole enterprise loses, and that’s it. This is also the theme of Linchpin. Two recessions later we are still learning the same lessons, funny that. Those lessons being that creativity and what Peters terms “emotional labour” (as in giving it some heart and caring about it) will keep you fed, but charging to the bottom won’t.

Both authors say that if you’re stuck somewhere you can’t do “emotional labour” or become a Linchpin – move on. Good advice.

View all my reviews

http://www.theregister.co.uk/2010/12/27/amazon_holiday_sales_stats

It works and comparing it with an iPad is silly, it costs less than a quarter of the price. I was interested in an iPad for reading stuff (have actually read a ton of things on my old iPhone) and the Kindle made economic sense.

Kindle will also do a Steven Hawking reading thing, which I plug into the car. Not brilliant, but means I’m still doing useful stuff when commuting.

Also switched to an HTC Desire, because it just works and has buttons with labels on that say things like “back” and “menu” instead of having to guess where the app has buried them in the user interface. Plus I can check my diary, twitter and email from the desktop without starting an app. When the new Android 3 devices come down the pipe, costing around £200, I’ll probably get one and be able to do about 10x more than the folk with iPads. Then I will give the Kindle to my other half.

Grateful to Apple for breaking the network’s monopoly and assumption that their users are stupid, but moved on. Also moved on from O2’s non-3G 3G and 500MB tariff to T-Mobile 3GB standard package. Plus the hassle free MiFi that’s built in, so I could use the phone with the Kindle … hmmm.

Imported Comments:

Chuck J Hardy

Kindle + iPhone 4, yet agreed

This is the first in a series of essays about what it means to be an Agile Practitioner, at least from where I stand. Agile has a venerable history and started from a sense of dissatisfaction with existing practices and methods. I’ve heard lots of people say that they’ve “done Agile” and it didn’t work. I overheard a project manager saying that it doesn’t work, or only works in certain situations, to the sage nodding of the guys around him.

I wanted to shout oh yes it does!

But there are a lot of things it isn’t:

• A set of rules
• Diagramming conventions
• No documentation vs too much documentation

What I’m reaching for here is that it’s a state of mind. This is hard to explain to people. In essence you can do what Burger King once said to Tom Peters Even when we did it right the first time it was still pretty average.¹ If all you do is follow procedures, treating people (particularly that stubborn breed of cat called a Developer) like they can be programmed then you get something that is really average, the sum of mediocrity. Sure, it will probably work, but be buggy and poor – so what? 

Agile started as a movement when a group of practitioners got together and wrote the  Agile Manifesto2. In essence, put the customer at the centre of what you do, and have an approach that lets you change your mind easily without lots of documentation and other things that create inertia:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This has practical implications for anyone who wants to write software, or do anything involving thinking and planning with other people. One of the eye openers for me was where the principles section of the site says Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. This meant that change is not the enemy, a feeling that had been driving me on for a long time. It also means that change requests are not an excuse to charge exorbitant sums of cash. I had worked on projects where you walked into a room the size of a football pitch and saw a number of people in a dozen teams (one project I worked on had 200 people in “the room” and didn’t include another 50 or so in portakabins outside and dotted all over Europe). You knew you were doomed when you walked through the door. The enemies of productivity, of getting things done, are (in no particular order):

• Bureaucracy – documentation for its own sake
• Large teams with no focus – documentation as a poor communication medium
• Process replacing understanding – documentation, anyone?
• Meetings “explaining” (i.e. mandating often inappropriate) architecture – pictures and discussion about fit, anyone?
• Meetings about meetings (this does happen)
• Unfocussed lone consultants on site saying “yes” to the client but not feeding anything back³
• Progress reports when the project is less than a day old – “it’s procedure” (oh, F-off)
• Whole team meetings stopping coding
• Meetings that could be summarised in a two paragraph email
• Control freak meetings (as in you have to explain things to someone senior who won’t understand what you’re doing over and over again) – these are also sometimes massaging the Project Manager’s ego meetings.

If you want a refreshing take on meetings, read Rework⁴

You can get things done with a traditional large team (or in practice set of teams mediated through yards of documentation and meetings) but it’s hard to do well, and expensive too. I used to work for the database company Oracle and we were very good at delivery (then, no idea if it’s still true). On site we would always do our best to make sure that we left the customer with something they could use. A common complaint from the on site team was that you’d spend the first four months of a six month project writing about what you were going to do in an incomprehensibly boring pile of document templates generated from Microsoft Word macros (the macro suite was called Oracle Method, funnily enough). Piles of words on top of each other, with the occasional code fragment – sometimes there were so many code fragments you could  have pasted them in and probably had some working software. I remember starting a rebellion and putting some before and after pictures in the documents and losing several yards of verbose technical text that people who didn’t have English as a first language would really have struggled with (and there were lots of them). It followed the utterly mad waterfall (don’t forget that each of these phrases has the words and sign off at the end – usually four signatories):

• Functional specification
• Technical specification
• Design document
• Implementation document
• Some code actually gets written
• Unit test documentation
• Functional test documentation
• User acceptance test documentation
• System test documentation
• Fluffy cloud documentation
• Finally we can go home and cry documentation (ok, I’m being silly now)

If something has been signed off then you have to go into Change Control – oh, the pain, the meetings about nothing. The cost!

We rebelled and merged functional and technical on one project. This saved us over a month of elapsed time. Consultants (or at least their management and sales force) and governments (tasty bureaucracy, yum) love this approach because you can bill for it and it looks like you’re doing something. But you aren’t. It’s bullshit business (as in busy-ness) and doesn’t get much useful done. One of my colleagues said: I didn’t join Oracle to spend all day using Microsoft products. This was terribly funny, because Oracle corporately saw Microsoft as the enemy, the devil incarnate, and yet they’d invested in this sub-product written in Word Basic that generated all these templates and employed people as auditors running around making sure they were being used. I’m finding it hard not to write swear words here, it was unbelievable, it was insane and we did it because everybody else did it. Did I say I joined Oracle from working at KPMG Management Consultants? This is not a critique of Oracle, it’s a critique of everybody around at the time. When all you have is the Waterfall approach then everything turns into one.

So I read the Agile Manifesto as a breath of fresh air against all this crazy shit. And yes, shit is the right word, honestly.

There was some confusion in my mind because I was switching to using Object Oriented techniques, e.g. learning to write use cases and follow slightly less crazy methodologies like RUP⁵ – which is still mind-bogglingly bureaucratic and was bought by IBM (surprised???). RUP has some good things in it, like the artefacts (i.e. documents of one form or another) are not mandatory and you pick the ones that work for your project. Also you do a risk analysis on project inception and do the risky things first, this means you can make sure you deliver something useful or, worst case, discover that you can’t deliver anything within your budget before spending a ton of cash on failure. So it’s definitely better than pure consultancy-driven waterfall. I never really got into UML (oh, the UML, sorry) because I was already a hard-core user of Oracle Designer and, if you start from the database like I was taught UML is an inferior way to describe relationships (disagree if you want to, like I care, honestly). UML works well in those insanely large projects with bazillions of dependencies and abstraction layers, but of course that’s where it came from.

Thing is, in 2002-3 North West England, as an Oracle PL/SQL specialist learning and getting certified in Java, it was impossible to find people who were using Agile. Whether it was XP, Scrum, Kanban, or roll your own. So I made an agile approach of my own work, questioning documents where code will do and drawing pictures instead of using lots of words. Wherever possible delivering working software. Testing software in the crucible of real people actually using it. 

I switched to using Ruby on Rails (RoR) after falling out of love with Java. I think Java is a language tailor-made for bureaucracy: curly braces everywhere, endless cruft from limitations of the language, no syntax for common stuff, use yet another class in the standard library, lots of useless layers in J2EE, “agnostic” approaches that mean configuration options coming out of your arse, 20-minute Ant builds, strong typing, everything verb has to be wrapped in a noun – no wonder corporations and consultancies love it, the bloat is built in right from the start. Again, Ruby set my mind free to worry about delivering working software. The other thing from RoR is I caught the test-driven bug. I tend not to write software without tests anymore, at least for production code. I’m not sure how purist Agile this is, except that it allows you to change your mind without breaking things which is a key need for Agile thinking. I recently put one of my own projects on pause while I got the tests working after migrating to Rails 3. Yes, it cost me a couple of weeks part-time, and no, I wasn’t going to compromise.

I also like RoR because it starts from the database. Code is built using generators, and some tests are also built in. But you start from a data-centric place. Not some pretty design done by a designer, but from the data. I believe that working software comes from data. As in, understanding the data flow means you understand the business you’re working with. But on the other hand, I’ve also worked with beautiful data models from Oracle Designer Generator that created software you couldn’t use because it was technically correct but very hostile. As usual the middle way (which appeals to me as a committed Buddhist) is the most sensible one. Rails makes it easy to find the middle way between data and design because it doesn’t sweat the simple stuff, and lets you be very strict about how your model is used.

So, I will move on and start the next essay in this series in a few days. Talking about the Agile heart, as against the Bureaucratic Tendency – you can measure bureaucracy so it’s popular (ISO 9001 certified shops take note). You have to do agility, and think, and care about what you do and how your customers feel, so it’s as much a feeling as anything else. A feeling that leaves your competitors behind, though.

¹ Tom Peters Circle of Innovation, 1997

²http://agilemanifesto.org

³ Anyone else worked with Earnst and Young back in the day?

⁴DHH and Jason Fried, Rework, 2010

⁵ Rational Unified Process. Methodology used to sell the Rational Rose modelling tool. I think the Rational was dropped when IBM bought it.

Imported Comments:

Ralf Westphal

Being agile as a state of mind. Yes, I guess that´s it. Even though I call it a lifestyle I guess we mean the same: agility is not something you switch on while you´re in a software project meeting.

I see a lot of people claiming to be agile – and when they´re buying a coffee machine they browse the internet for hours, read reviews on end, check every store in tone to know exactly what´s the best offer. To me that´s a contradiction and I always wonder how agile their projects really are.

If someone claims to be agile and it does not show every minute of his life… then something is missing.

As for “As in, understanding the data flow means you understand the business you’re working with.”: That´s a great observation. But I´d like to ask: And then? What do you do once you see the data flow. How do you get from there to code? By translating data flows into domain object models?

-Ralf Westphal
http://geekswithblogs.com/architectsnapkin

Francis

Thanks for the comment Ralph!

I agree the data flow comment isn’t very detailed – it was more of a
reaction to when I see designers go mad with half understood
requirements and we end up with a mess. The data flow, for me, always
tells the truth. But then I’m an old database hacker 🙂

I just got myself an HTC Desire and logged in here It’s interesting how I feel more comfortable using it compared to my now pretty crusty iPhone 3G. Still a bit laborious to type anything long on it but I think I’ll get up to speed quite quickly.