As always, Jeff Atwood has an interesting around code being our enemy as developers. His proposal is that code needs to have better ‘brevity’.

I don’t think Jeff is talking about Brevity – and I think he even says that – but about Clarity. Clarity is simple, obvious, and to the heart of the matter. Real clarity is brief, but easy to read. That includes comments, too.

It could be made shorter in ‘text speak’, but how clear are those messages? There is a reason we don’t use 1 letter variable names!

It’s not tiny fragments of obscure code that does massive amounts (yes, I’m thinking of Perl in that, amongst others). And it sure as hell isn’t about lines of code – many languages (with notable exceptions) let you put an entire program on one line. Ever tried reading one? I did – you can’t.

It’s just about being simple, clear, and to the point. It’s kind of like Buddhist enlightnment – someday, with enough practice, I’d might just achieve that.

Unfortunately, I do think that we’re constrained – people often expect very complex things and lots of features from their software, and when people are demanding complex programs, you get complex code. Look at the complexity cost of, say, just having a simple UI for a Windows app, as opposed to a console app.

Some of the comments are very good, too. ‘Mickey’ is right – often, we’re trapped by bloated design. KISS is my watchword (and occasionally gets me a slap too).

Fred Ross is right, too, in his comment about code maintenance – but he does miss the point that often we’re under pressure from the boss to ‘just get it done’, and the idea of ‘get it done, but in a way that will save us time later’, well, usually, that dog won’t hunt.

Someday, we’ll get past the idea of using lines of code as a metric for how ‘good’ code is. I guess the problem is that clarity is more ethereal.

Comments from my old blog:

I agree with most of your points – but diverge in perhaps the same places you might too.

Examples… a typical .NET web application – which has C#, HTML, DHTML, Javascript, horrific call backs for AJAX, SQL, Stored procedures, triggers… the list goes on. There doesn’t seem to be any sensible way of making it “simple”.

The other problem (at least in my recent experience) is RAD or AGILE development… which often leads to spaghetti code unless the client is willing to pay a huge code tax for re-writing swathes of the project.

By Jonathan at 09:20:28 Tuesday 5th June 2007

Though I did have a demo at a potential customer recently, this isn’t about them. These are just the things that I’ve seen repeatedly. I’m not sure what the answers to some of them are yet.

1. The (potential) customer always wants to see 90% of the functionality in the demo – no matter how custom that development is. (This is a case of managing expectations)
2. The complexity of the demo is inversely proportionate to the time available to build it. (Beat the salesman until he understands, then cut all the complex bits and proceed as above)
3. The customer will want to see all logins for all the different users in a process used – and will then yawn as you switch between accounts (and yes, I know about ‘Run As…’. Even so, they’ll yawn). (Don’t show it. Or do it once, and then explain that you’re going to stop switching for the sake of sanity/getting to lunch on time)
4. The bit that you spend ages on getting working because it “must be shown” won’t be shown. (Try to find out how important these hard parts really are)
5. The bit that you spend 5 minutes on, doesn’t do anything, but looks pretty will get them really excited. (This is good! Make sure you show them the exciting stuff)
6. The customer will be utterly confident that they know their business process – and then through the course of the demo show that they don’t. (Try to help them see this, and consider re-engineering/redfining the process. If they won’t, steer clear or work on a T&M basis…)

I’ve been testing some code I’ve written for sending out notification emails according to a moderately complex set of rules. So, what have I learnt?

• Developers make rubbish testers. We know our own code too well, and already have expectations of how things should work.
• Testing has too many variables for any reasonable size application. You can’t test exhaustively. Equally, testing only what you think needs testing will also miss things. I’m beginning to think some automated, semi random testing (if you can) is the way forward – and you’ll still miss things.
• Specialist testers are good. I’m convinced a specialist would see what I’ve missed, and have good ideas over how to test generally. I don’t think I’m alone in that..
• Automated test is not a panacea… I really don’t see how it could apply in this case, at least not without a unit test program that could create database records, read a SharePoint library, and read an exchange server. All reasonable – but how do I then test the test app? ‘Cos it’s a complicated as my actual application.
• … and Unit testing isn’t a panacea either… I know, they’re related, but this does at least imply that you’re testing, well, small units of code. That relies on problems not occuring because of mismatches in the interoperation between units.
• … and with them both, you have to remember that you’re designing the tests. If you didn’t think of the case to handle it in your code, do you think you’ll think of it to test for it?

All that said, my application seems to work pretty well. Just there was a lot of manual cross referencing of results to check things worked, so I had a lot of time to think.

I’d really like a project where I can get thoroughly stuck into unit testing. Didn’t use it in this one, but I did think about how I would’ve done it – and I suspect I’d have missed one of the bugs I found. I suspect that unit testing’s main advantages are in forcing developers to actually think up front (sometimes rare), and in ensuring a consistent public interface despite internal changes. But I don’t see how you can get away from the fact that someone has to site and decide what to test – and that way things can be missed..

Two fascinating articles. I agree with Marcus Ranum, it is interesting how in Feynman’s “Personal observations on the reliability of the shuttle” highlights the good quality of the software. Given how software is usually so bad, how did this happen? Well, it seems that NASA recognised that testing is expensive and hard, and that ‘have you tried rebooting’ is not an adequate answer to a problem. Good testing takes time, money and aggressive pursuit of something better than ‘good enough’.

Those boys at NASA clearly understand software testing. After all, it ain’t rocket science.

Control is a closed loop process.

You have some input, something happens, you look at the output and adjust your input again. This is implicit in quality procedures everywhere. This is what testing is.

Over the last few days I’ve been asked to estimate how long various bits of work for a potential customer will take. I’ve tried to make good estimates, but the truth is that I have never seen a comparison of how long was estimated at the beginning of a project, and how long was actually taken.

In other words, I still only have my gut feeling, my perceptions, to guide me as to how accurate I think my estimates are, despite the fact that this is a clearly measurable metric. The control loop is still open.

At the moment I provide estimates like “I think it’ll take about 10 days, but I’m not really very sure”. Wouldn’t it be better to know “Andy normally under estimates by and average of 10%, with a standard deviation of 10%”. Then if, for example, I estimated 10 days, we’d know that it’d actually 10-12 days, but only 68% of the time, or 9-13 days 96% of the time.

Perhaps this exercise is performed at a management level already – but as the developers are being the ones asked to estimate for technical details, it’s us that need our accuracy fed back for those aspects.

Now, I realise that there’s always going to be a human aspect to providing an estimate, that projects often aren’t that clear and easy to cut up, and that often we’re working with new things that we simply aren’t sure about. There’s also a cost-benefit question as to the effort in feeding back accuracy data. But I think that there are broad trends we should be able pull out.

I guess what I’m thinking is that we should have a process for optimising our estimates. I guess that this would involve examining statistical methodology. The best we’ve got at the moment is an informal “well that look longer/less time than I thought” after we’ve completed some work – and over projects that can span years, you just lose track.

It does strike me that it should be straight-forward to collate this data, and then feed it back at the end of the project. Close the loop. Regain some control.

Some useful links to things to remember in testing in Coding Horror. I agree; developers are poor testers, and the guy who wrote it is the worst person to do testing.

I said I’d follow up my earlier wondering into bespoke software vs huge applications, after I’d thought a bit about why companies don’t seem to like small, bespoke apps. Continue reading “Bespoke Software II” →

Cost aside, given the choice between a suit ‘off the shelf’ and one ‘made to measure’ in Saville Row, most people would go for tailored suit every time. So why doesn’t that happen in software?

Okay, so I know I just made that comparison so that it wasn’t like-for-like by excluding cost, but it seems to me that tailors are a good analogy – and that the shopping habits of the well dressed man and the well equiped company are quite different.

Consider the suit. You can buy one ‘off the shelf’. It won’t fit as well as one made specially for you, but it might fit well enough. Sure, the legs might be a little long, and it’s a little broad across the back, but hey, it’s a lot cheaper.

Another option would be to get a bespoke suit. Bespoke it a wonderful word that makes me think of bicycles, but here I mean it as ‘made to measure’. You suit will be unique, comfortable and well fitting, and it’ll cost much, much more. I know I’ll have made it when I get a bespoke suit.

The third option is to get the cheap suit, and have some alterations done. That is, you get someone to make small changes to the cheaper suit, so you get a better fit, and it still costs less.

Software is the same. It can be made for you, you can buy it off the shelf, or you can buy it and hack it until it does what you want it to. (I mean ‘hack’ in the old school way, not the illegal way).

Most people, when they buy suits, just keep shopping until they find one that fits. The luck few (or those unlucky enough to have unusual measurements) get them made for them.

Companies and software doesn’t seem to be the same though. They’re in all shapes and sizes, and as profitability often depends on good software enabling your processes, they all want suits that fit very, very well.

Lucky companies can find a bit of software that fits just perfectly, and within specialised fields, there are products like that. This is great – the suit is cheap and fits well. However, most companies have oddities that mean, for certain applications, no software fits very well. I guess, companies have less regular measurements than people.

So, now they’ve got a choice – bespoke, or get something and customise it. Actually, here the analogy breaks down a bit – there is a third option. Some software is built to be highly flexible and adaptable, so that it can fit many jobs. I kind of think of this as a ‘shrink to fit’ suit – I know, it’s straining. Humour me.

Okay, so, imagine we get some software and decide to customise it. Customisation costs, and it means that what you’ve got isn’t exactly the same as anyone else. You need someone to figure out what needs done, and make the changes for you. The constraints of the system can make some of those changes hard. Indeed, if the software fits poorly enough, you can end up having to rip the whole thing apart and rebuild it to do what you wanted to (Been there, done that). Indeed, you might as well have had it made bespoke.

Alternatively, you could use a ‘shrink to fit’ option. I think Microsoft SharePoint 2007 is a great example of that. It’s very flexible, with all sorts of neat bells and whistles, so it will fit many, many different needs. The problem is configuring it, shrinking it so that it fits well is also made very hard by this. Again, you’re into the realms of needing a specialist to help you. And you might not even need all those bells and whistles. At the end of it all, it could be as bad as having someone dismantle it.

So finally, we come to bespoke. You get someone to make it specifically for you. It does the what you want it to, and only that. You’re not paying for bells and whistles, and as it is designed to do just what it does, it is simpler than the other options. Sure, the tailors costs are a little scary – but done right, you don’t get all sorts of extra cost creep in later.

I keep ‘seeing’ bespoke solutions. I’m not working on them – I’m probably hacking around with some third-party application again, trying to make it do what the customer wants – and this vision comes into mind of what I could build to solve just that problem. Normally, they solve just a single problem – but do that well. And I wish I could do them. It seems to me that development is become faster, and frameworks are becoming better. Look at Ruby on Rails – it gives so much for free, you can really build an application quickly in it. Even (though I hate to admit it) Visual Studio can give you a lot, sometimes – although it is collapsing under the weight of trying to be all things to all people.

So my question is this – why do companies seem so keen to stay away from an application that just does what they need it to, and yet happy to buy something off-the-shelf and then have to change it to do what they want it to?

I guess I’ll consider that later…

When you say ‘soup-to-nuts’, we don’t know what it means. Frankly, it sounds like a potentially painful accident (depending on the temperature of the soup).

I looked it up. It means ‘end-to-end’. Why not use ‘end-to-end’ then? We all need to avoid strange localisms in our language. I mean, I’ve never finished a meal with nuts. Cheese or coffee, yes, but never nuts.

And the word ‘doable’ is not a word – we’ve already got a word for that anyway, and it is possible.

I’m guilty too – I used “elephant in the room” for a bit of humour. Completely confused my Zimbabwean colleague with that phrase. Presumably, elephants in rooms really was more of a problem for him.