Log in

No account? Create an account
latest entries related journals calendar about the author My life in pictures older entries older entries more recent entries more recent entries
Just when you think you're the only one suffering... - My Thoughts Today
An ill-used association of words and pictures
Just when you think you're the only one suffering...
...you happen upon a really cool blog post that reaffirms what you've always believed - genuine talent goes unrewarded. The author Zed Shaw has for a long time been well-known in the Ruby scene because of his cool code and ingenious projects like the Mongrel web server, so to see him laying down home truths is refreshing even if the fact that he's walking away from the language is a sad blow - along with Why and the JRuby team he's been one of the most creative people in the community and his cleverness will be sorely missed.

Ruby is one of the coolest languages I've encountered in twenty-six years of learning new languages. I try to learn every new language I meet and that's why I got into coding in the first place - to develop languages and understand how a few statements that looked roughly like English could make a machine that only understands 1s and 0s perform interesting tasks. I know that language geekery in the linguistic sense is a minority interest amongst developers, most of whom only want derivatives of C (C++/Java/C#, etc.), but that's what sucked me in aged eleven, and that's what keeps me here today.

So when I say I love Ruby, it's not because of the hype or because of any particular implementation. It's because linguistically it's a beautiful and powerful language, the marriage of Lisp's elegance with Basic's simplicity. It's the language I wish I'd had when I first started out, and by now I'd actually be as good a Lisp hacker as I've always aspired to but never quite pulled off.

But Ruby has a problem. Well a couple of problems really. Current implementations still lag behind where I'd like performance-wise - kudos to both Charlie and Ezra for their respective implementations, but most of us are still using Matz's and that's pretty sluggish. Those kind of problems get solved with time though, so it's no biggy. Far more troubling though is the cult-like following that camps on the language's fringe.

You see in the tradition of Greek tragedy Ruby is cursed by the worst of all offspring, that supposed killer web development framework Rails. Rails itself is interesting technology, and certain of its components (like ActiveRecord) are beautifully conceived and implemented. DHH had a moment of revelation and that's turned out to be so powerful that it's made even Sun and Microsoft quake. However Rails has become the proverbial tail wagging the Ruby dog, or more to the point the Rails community - which in general has no particular affiliation with Ruby itself - has become the public embodiment of Ruby. So much so that my colleague spikyblackcat and I have to talk at Rails conferences if we want to demonstrate the cool stuff that can be done with Ruby and reach anything like a decent sized audience.

The thing that strikes us every time we do this is the complete incomprehension our audiences display for what are essentially simple little coding tricks. Tricks that anyone who spent more than five minutes learning the core language would spot. Neither of us is in Why's league, but we still blow minds so apparently Rails developers don't learn Ruby, they learn Rails. That's like a mechanic setting up in business fixing cars when they've only studied the sales brochure for a Citroen Zsara - the moment they're outside that comfort zone they're screwed.

And the Rails world is screwed.

It's screwed by the myth of test-driven development, which in general means that instead of writing well-thought-out code developers hack some stuff together based on some tests, and if it passes the tests they consider it fit for purpose. In fact I've been told by a rather well-known proponent of Agile that that's the very best way to write code.

Now until I meet someone who can show that they've done something significant by my personal yardstick - full end-to-end design, implementation and certification of a cockpit navigation and control system - I will remain the best-qualified person in the room on the subject of code quality and fitness for purpose, because as I routinely harp on about when I'm in a ranting mood I have done that, and in visual basic too. That was achieved the old-fashioned way, by figuring out the requirements and implementing them with lots of ad hoc testing during development based on execution path analysis and black/white boxing, etc. Generally those kinds of test are disposable because of the pace of code mutation if you're looking for an optimal implementation, so I rarely keep test suites.

The counter argument to the way that I work is based on the notion of continuous integration. Supposedly that's only practical if after every addition to the codebase a full set of tests can be run to make sure things aren't broken, but I find that a very strange requirement to place on any development process. Why does every version of the codebase always have to deployable? That's an ideological nonsense. I agree that broken code shouldn't be deployed except as an alpha or beta for client/customer approval, but that doesn't mean that you can't have broken code in your development branch for the days or weeks it takes to solve a particular problem. But I guess if ideology is what drives you, you're going to need an excessive test suite.

Test driven development may help continuous integration, but it won't get you any closer to valid requirements and optimal code because that's not its purpose. TDD about letting you write code that tracks back to a test which tracks back to an ad hoc requirement, telling you nothing about the context of that requirement or whether or not it's a good requirement. Don't chain yourself to TDD, instead do some proper analysis work because overall it's less effort and gives a much bigger payoff in code quality.

Aside from TDD there's also this notion of agile coding that I recently ranted about. Agile is a good thing if you stick to the core aspirations of the manifesto, keep your teams as small as physically possible, are clear about what you want to develop and don't let process or technological prejudice stand in the way of cleverness and exploration of the problem domain. Unfortunately software development is rife with shoddy hacks who only got into it to make money and for whom the ability to really grok a problem is so alien that they would rather spend millions of pounds on other shoddy developers with a well-known process than fifty thousand pounds to hire one good developer to do the same project in the same - or shorter - timeframe with a more pragmatic approach. I get so hot and bothered by this attitude that I'm going to throw some stones for a while at the more popular defences business people use to defend it.

Conformity === Quality

Well, in the sense that once everything conforms to a certain standard you can at least talk about uniform quality I guess. The funny thing about software is that the small number of people who are really good at it rarely are conformist by nature, but the code they write is of considerably higher quality than the norm. They also tend to code for the pleasure of it, make the mistake of taking jobs on risky but satisfying projects, earn much less than they could wearing a suit and tie and working conventional hours, display poor punctuality and a lack of concern for the corporate hierarchy, etc. They are mavericks and that's what makes them both so damn frustrating to work with, and so damn good at what they do.

Show me a coding shop without any mavericks - the people we used to affectionately call Boffins when plucky little Britain still cared about technical talent and creativity - and I'll show you a hell-hole of crap code and poorly researched requirements. Ever run into stories, those stupid little functional fragments that get passed off as requirements in the XP world? Then you'll know exactly what I mean.

Add to this that monocultures are intrinsically fragile, lacking the diversity needed to survive changing environmental conditions, and the idea that conformity is a good thing looks like a classic example of maladaption at work.

It's all about the Budget

The I know the price of everything, but the value of nothing defence. Many people put this down to accountants but the truth of the matter is that business people value money much more than they do the intellectual capital that generates wealth and set they're budgets accordingly. Unfortunately intellectual capital is very expensive to replace once you've lost it, because generally it's locked in the heads of employees and can take years to recreate. Sometimes it's not even possible to do so, and when a key employee leaves the business suffers irreperable damage. But that doesn't stop many supposedly competent managers from driving expertise out of their companies.

Good Programmers are hard to spot

Call me naive (many people have) but I believe that one good developer can spot another good developer based on about five minutes of chatting over a beer, because the good developers know their subject in depth and will have exciting personal projects to talk about. The real test though is the variety of bullshit they engage in as the beer count increases: generally it's the creative kind that makes you want to find out what they're trying not to talk about (that's probably covered by NDAs) and time just flies by.

Bad developers on the other hand will bore you rigid with waffle about this role they had at such-and-such big name company, or how much value they added on some boring-as-hell enterprise system, or why some trivial failing of a particular platform made it impossible to do something. Let's face it, good developers don't let platforms get in the way - if they have to write dodgy, unstable, hideous hacks to get something to work that's what they'll do and then spend the rest of their careers telling all and sundry about it because they've earnt the right to brag.

However the corporate attitude seems to be that coding tests are the way to spot good programmers. That means corporates will mostly hire programmers who produce safe, textbook solutions to generally dull and tedious problems. I guess that's one definition of a good programmer - one that you can rely upon to fit in neatly and interchangeably - but that's not going to spot real talent.

Still I guess you have to attract that first good developer before you have a chance to learn the difference, and if you insist on a culture that enforces conformity and bureaucracy I'm at a loss to understand why a good developer would want to work for you in the first place. Business people know this is a problem which is probably why I keep hearing them talk about adopting open source practices and it always leaves me wanting to say the same thing, "it's not the practices that make open souce work you morons, it's the fact that they're interesting projects and attract good developers who want to work on them for free because it's fun."

Big teams are good

Not that it's ever phrased that way. Big teams are universally accepted as a bad thing, but ever since Agile become the dominant meme we've been suffering the pair programming obsession. It's a bit like that scene in Mad Max Beyond Thunderdome: two go in, one comes out. By which I mean, two programmers get sat down together with one workstation and supposedly as a result of synergistic interactions they produce much better code than they would individually. I've ranted about this before so I won't repeat myself. I wouldn't stop anyone doing it if that's there idea of fun, but the idea of doubling my team size just to suit a religious preference strikes me as lunacy. I want my teams to be three people or less because experience tells me that's the sweet spot for producing good quality code on a tight budget.

Risk is Bad

One of the dirty truths of software development is that the vast majority of projects will fail to meet their objectives, and they will do so for purely human reasons. To start with most software pretty much writes itself once you get into it, with a few problem areas along the way where the machine refuses to see things the way you want, but most code is the mechanical fluff that any trained multicellular organism with an understanding of boolean logic should be able to write. Unfortunately a sizeable minority of programmers fall short of that mark, so you've got technical problems built in from the start and as time goes on that will sufficiently disturb management types that they'll start looking for voodoo hoodoo to compensate.

The whole Java/J2EE/OO/Design Patterns cult is one such voodoo, and for some people it works really well. There are people in the City building incredible data analysis tools using this technology and I respect that. But because it works for them doesn't mean it works for everybody, every time. That's the nature of risk - it's no respecter of fashion or perceived wisdom and you can only get a handle on it by studying a particular problem domain in reasonable depth. It's also pervasive. Contrary to popular opinion amongst business folks though, risk is a good thing. All the most interesting projects are risky, both financially and technologically, but when they pay off they do so out of all proportion to the obstacles. In fact it's the key thing I look for when taking on new projects because it guarantees I'll be using all of my skills to the fullest and will get to solve significant problems.

The trick with risk isn't so much in minimising it by playing safe, as in doing your homework properly and making contingency plans for when a particular course of action doesn't pay off. Backtracking decisions and being flexible is the name of the game, hence the idea of being agile and using small teams. What this requires though is strategic thinking and apparently apparently that's difficult if highly paid business consultants are to be believed. Personally I suggest you can spend a few weekends playing computer games like Europa Universalis and you'll soon get the hang of on-the-fly strategic thinking, but as no one believes that a good education can cost you as little as £20, let's have a look at cost...

Expensive === Less Dumb

I hate consultants. Not the freelance contractors mind whom you turn to when you need a given skill, but the large corporates who present themselves as experts with only the best on their payroll. Given that many of these consultancies place high value on recruiting employees with excellent academic qualifications, it's easy for them to present themselves as la crème de la crème, and people in management rarely seem to look at the substance behind academic backgrounds. Got an MBA from MIT? That'll do nicely.

Well another clue for anyone in search of a genuine edge: with rare exceptions the straight A students were too busy studying to hack much code in their spare time, and therefore they're orders of magnitude less likely to grok technology than those C-grade, scruffy, couldn't care less about your idea of office hours and decorum hackers that you consider so risky.

Large consulting firms follow the latest 'hot' technologies as that's where the money is, but strangely they rarely seem to hire the experts in those fields. That means you're paying premium rates for second-rate advice cobbled together on the fly by someone with minimal experience. To add insult to injury they'll often offer training courses to help their clients get up to speed in these technologies, and if what I've seen of these in recent months is anything to go by your inhouse developers and business analysts would be better served by a two week, all-expenses-paid holiday than one of these brainwashing shams. Not that I care - like most hardcore hackers I'm immune to these sorts of seminars because I can analyse them and see what's going on. So if other people want to pour good money into the pockets of parasites I consider that their business. Literally. Just don't be surprised when you discover that expensive just means you're being milked for all you're worth.

How do I come to that conclusion? Well a genuinely competent freelance developer is going to put maybe a 50% or 100% markup on their work, because they have overheads and slack periods, tax bills to save for and equipment to buy. Under some circumstances this can work out a reasonable cost saving compared to hiring a full-time employee, and the chances are that the freelancer takes pride in doing their job swiftly and efficiently so the return on investment should be high. Unfortunately the average developer from one of the large consulting firms is likely to have a 300+% markup put on their salary, and that's a far less understandable expense. By way of comparison:

mode of employment 1 developer per annum 5 developers per annum
in house £35k + employment costs £175k + employment costs
freelance £70k £350k
consultancy firm £160k £800k

So where you can hire five decent developers for a year at a headline cost of £175k, the same developers on hire from a consultancy firm could easily cost £800k. Sure you'll have employment costs on the five developers if they're inhouse, but it's unlikely those costs will add up to £625k!

Alas expensive always sells.. After all, who wants to be known for hiring the cheapest consultants in town? No one. And because most people who get software developed this way have no real yardstick against which to measure the quality of the product they get or the productivity of the people producing it, there's no good counter argument to going down that route. Well, not unless you're willing to resort to the same tactics as the consultancy firm: over-cost all viable alternatives; misrepresent what constitutes productivity; claim to have skills you demonstrably lack; and cut back all of those pesky requirements that were key to the project but represent genuine technical challenges.

By now you're probably wondering if this latest diatribe has a point, and I guess it doesn't beyond getting it off my chest. I'm definitely not the first programmer to rant against the big corporates and their practices, or to suggest that the hype around Rails is a bad thing, and I'll probably continue using it on future projects when I think it's appropriate because behind the hype and the flim-flam there is a pretty decent little framework that showcases some real Ruby neatness. I just wish that there were more of us who see it that way...

Tags: , ,
today I am mostly: aggravated
the music in my head: police sirens

15 opinions or participate
(Deleted comment)
feyeleanor From: feyeleanor Date: January 9th, 2008 02:03 pm (UTC) (permanent link)
Which comes as a bit of a relief :)
nickmurdoch From: nickmurdoch Date: January 9th, 2008 09:14 am (UTC) (permanent link)
Nice post! I pretty much all agree with that. I don't do anything as tough as life-critical systems myself, but I think most of that applies to building websites and stuff too.

We do actually have a Python test at work for interviewees, but it's just a quick ten questions to make sure they know about the basics of python -- as you mentioned with Rails, a lot of people know how to do something specific in the language but aren't too hot on its details. The number of issues people have with Unicode, for example, on python lists is quite insane!
feyeleanor From: feyeleanor Date: January 9th, 2008 02:04 pm (UTC) (permanent link)
I can see the point of quick 'do you know operator precedence' type tests when a candidate looks a bit weak, but I'm really much more interested in the reasoning behind code than I am the actual code itself - poor style or lack of depth can be cured with experience, but sloppy thinking can't...
hsb From: hsb Date: January 9th, 2008 01:20 pm (UTC) (permanent link)
Um, may I request a cut tag? 's looooong

feyeleanor From: feyeleanor Date: January 9th, 2008 02:09 pm (UTC) (permanent link)
Just for you dear ;)
(Deleted comment)
(Deleted comment)
feyeleanor From: feyeleanor Date: January 12th, 2008 11:35 pm (UTC) (permanent link)
When I worked on bespoke systems it used to irk me that my daily hire rate was a fortnight's salary, but we were the only company on the market able to offer the systems that we did and I understood that £1500 per day represented what it actually cost us to get the work in the forst place. We didn't sell based on being the cheapest, we instead focused on being the cleverest (and at the risk of sounding arrogant, that's exactly what we were). Our clients were big enough that they could have afforded to develop their systems in house, but there was an obvious benefit to them in using our product because it was also used by their competitors and we were dedicated to making it the most user-efficient system it could be.

What lies behind my current ire isn't so much companies having software developed externally, so much as the fact that they do so for the wrong reasons. A consultancy can never deliver software at the cheapest cost, so the decision to outsource should be madefor technical reasons. It should be about the actual skill of the outsourcing partner to deliver the software that's desired, and that's where I think many companies make a huge miscalculation.

As you mention in your other comment, the theory with outsourcing is that instead of one good developer with limited skills you can rely on a large pool of developers with a broad range of skills. But I'd question the reality of this. A good developer can generally turn their hand to any technology and the overhead may be a week here or there to slip into the right gear, but most people who employ developers have this inbuilt assumption that unless a skill is on a CV it will require hiring a new member of staff to cover it - and compared to that the costs of outsourcing suddenly look much more favourable.

I'[d argue that hiring good developers with strong instincts obviates this benefit, but I've now worked on two major projects where the people paying the bills could not accept this reality. As a developer this is frustrating because you see the scope reduced to a facile level and the resulting project handed over to another coding team at an inflated price, apparently rewarding a lack of ambition. That reality really hurts.

My whole career is has been founded on delivering projects of ambitious scope, and for the last two years I've been placed in a position where the people funding my work would rather spend ten times as much and get a fraction of what I would expect as the minimum deliverable. Either my expectations are unreasonable or else my employers have been lacking in ambition, but frankly I could never adopt the practices I railed against in this particular entry because I wouldn't get any satisfaction whatsoever from doing my job.

And the greatest irony of all is that I've earned more as an under-utilised spare wheel than I ever did as a freelancer...
feyeleanor From: feyeleanor Date: January 12th, 2008 11:37 pm (UTC) (permanent link)
Neither 1) nor 2) really stand up under close scrutiny. Especially 2) as the cost of litigation to enforce contract terms will more than outweigh the supposed saving...
From: centipedefarmer Date: January 10th, 2008 10:55 pm (UTC) (permanent link)
I had to start an LJ account just to comment. I loved this, except maybe the part about test-driven development. I don't use it all the time, but when I do, it helps a lot. The quicker I catch my bugs, the easier they are to find. Of course the problem with TDD is probably that if managers are enforcing it on programmers, by and large programmers who don't get it will do as little as possible to make them happy, or will write lots of really useless tests (be careful what you measure, you might get it).
feyeleanor From: feyeleanor Date: January 13th, 2008 12:06 am (UTC) (permanent link)
I think that's the best compliment my LJ's ever received - especially as I allow anonymous comments!

My views on TDD are driven by my background in physics. If you spend your formative years devising experiments it's hard to see a test as anything more than what it is - a quick insight into what's going on under the hood. The idea of writing tests in advance and then restricting my implementation to that particular set of preconceptions feels like an abdication of my duty to write the best software that I can to solve a given problem.

Oh, and just to horrify any TDD fans reading this entry, none of my significant systems have ever included a test suite. When I finish a project the code reads like English, performs appropriately for its purpose, and every line has been hand checked to ensure that it does what it says on the tin. The average software application contains 1 bug for every 300 lines of code whilst I've worked to aviation tolerances of 1 bug per 30,000 lines of code and TDD just won't deliver that. You have to live your code (and everyone else's) to do that.

And I guess that's what annoys me most about many proponents of TDD: instead of recognising that tests are a small window on their requirement space they claim that the tests are the true description of the system. What about non-fuinctionals? What about environmental conditions? What about contradictory requirements?

But it sounds like your outlook is more pragmatic than that so I don't think we'll be having an argument anytime soon ;)
From: centipedefarmer Date: January 13th, 2008 07:06 am (UTC) (permanent link)
For some reason I didn't /want/ to be anonymous on this one. It was some trouble though, as all of my usual stock screen names had been taken.
feyeleanor From: feyeleanor Date: February 12th, 2008 04:56 pm (UTC) (permanent link)
Register early, register often ;)
neilh From: neilh Date: January 11th, 2008 08:04 pm (UTC) (permanent link)
Agreed that most of these methodologies are about getting reasonable work from average employees. And they are not a replacement for understanding your requirements.

...but I have to say that testing has a significant place, most software in the modern age is involved in an integration process at some point in its lifecycle. Without the ability to demonstrate it conforms to interface specifications you end up with tens of teams of people chasing each other around claiming that someone else wrote the bug that stopped it all from working.
feyeleanor From: feyeleanor Date: January 13th, 2008 12:38 am (UTC) (permanent link)
As far as black box testing is concerned I completely agree with you. An API needs to be testable for developers to have confidence in it and to know how to write workarounds lol

I notice though that mainstream TDD doesn't make any distinction black box and white box testing concepts, or code path completion, cyclomatic redundancy, coupling, cohesion, decision matrices, non-functional testing or any of the other techniques that I rely upon in my embedded work. Nor have any of the documents I've read on the subject explained how the requirements which give rise to the tests are validated.

I guess I just believe that everyone should go and learn what testing is really about, and then apply it as needed to ensure that their code performs the way they intend rather than quoting code coverage metrics and insisting that those equate to quality.
neilh From: neilh Date: January 14th, 2008 10:08 pm (UTC) (permanent link)
TDD can work if you've got people who understand what its about, though perhaps I'd be more inclined to use 'Test Driven Coding' rather that design. Theres no substitute for the whole team sitting around a whiteboard for a couple of days at the begining of the project and figuring out a decent design for everything. That does both of making sure that everyone understands (at least to some extent) what the whole system does and gives everyone a feeling of ownership. If you own something you're more inclined to want to make it good. If you want to make it good you test it properly.

The industry as a whole is so bad at design and testing, quality in general. Its endemic, from the way managers recruit testers (they're second class citizens, straight from second rate universities and put on projects where they can't do any real damage) through the project plans which make testing that squishy bit of contingency at the end of the project to books written by people who have no idea about anything other than testing as something that should be done.
feyeleanor From: feyeleanor Date: February 12th, 2008 07:37 pm (UTC) (permanent link)
I so agree. Shared project ownership makes far more difference than any methodology because it focuses everyone on what really matters - writing good code. And people who write good code are generally the ones who've put the effort into reading code and trying to rewrite it so it's tighter, not the ones who sat in uni lectures believing in Waterfall, Agile or whatever this year's flavour of management philosophy is. Unfortunately these seem to be the very same people who get marginalised in industry...
15 opinions or participate