The x stages of software development

Some possible stages in the development of a system or a system developer…

1. You are amazed the computer did what you told it, not what you wanted it to.
2. You accept that any unexpected situation will kill your program, and there are lots of them
3. You trap most unexpected things and throw up a message box, usually.
4. You trap most unexpected things and stop gracefully, usually.
5. You trap and log most unexpected things providing a non intrusive report/status
6. You trap and recover successfully from many things, and log the rest.
7. Nothing is unexpected, in a Zen like ‘if a system fails but no one notices, did it fail?’ way
8. It moves to a SEP field (and here)

What did I miss?

Where do your systems normally end up?

What’s the highest you have reached?

Most of my quick and dirty stuff gets to a 4, production stuff gets to a 5 or 6 before skipping 7 and moving directly to 8.

And you?

cheers

Simon

XLL news

I have picked up a few snippets recently:

JetXLL is no more, the developers instead suggesting potential customers consider ExcelDNA.

It is testament to how mature Excel DNA already is, that commercial endeavours are now diverting potential customers that way. Its also testament to how important is this ‘.net to Excel UDF’, that so many people are using (and developing) these sort of bridge tools. Why Microsoft is incapable is beyond me. (Well its not actually but that’s another story).

KALX has made available a zip of their xll library. I demo’ed this lib at the xl dev conf in lndn a few months back (watch out for news of the May 2011 event!) its staggeringly easy to use. And now with direct access to the zip rather than needing an svn client its easy to download too. Well worth a look.

I’ll write up my thoughts and experiences with these and other tools as time goes on in my new ‘time with family’ mode.

cheers

Simon

Love documentation

One of my mates was asked if he likes documentation in a recent interview.

“No, I hate it” was his reply, or ‘I rushed so fast to get the no out that it almost came out as on’.

Hmmm, career limiting I thought.

Hmmm Hmmm, it only limits you in careers doing the type of job you don’t want though. Hmmm…

Me, I love relevant and useful documentation. Well, I think I would if I ever saw any.

Dick over on DDOE had a relevant interesting post recently. I was going to comment there, but after deleting two out of control rants I gave up. This point is very relevant having just binned my last role.

I look forward to hearing from the people who took over from me (if we are still friends ;-) ) what they think of my legacy. But I assume it will be like any builder who comes to your house. They always criticise the work of those that went before. That’s not to say I could have done a better handover. Or done some other stuff better either. (We found an error in some of my test SQL on my last day – it’s not my first or last error I’m sure).

My big point on this though is that Excel is best for tactical short term systems. And the dev process should match that short term, medium risk, medium value return. Heavyweight development processes with a documentation focus are inappropriate imo. Yes many of these things become business critical over time, at which time they should be reviewed/migrated with that new status in mind.

Anyone looking for a tactical Excel developer who loves documentation has got the wrong end of the stick I reckon.

Smurfs guide to good Excel system doco:

1. one paragraph description of what the system does from a business pov
2. a couple of pages of design overview about the big technology lumps that address those business needs
3. One sentence description of each worksheet, easy to find in each sheet
4. explanation of any complex formulas or queries
5. Meaningful variable and procedure names in code, table, query and field names in databases

Developers can work the rest out if and when they need to.

Too much documentation is written for managers who don’t understand the business problem being addressed or the technology used to address it.

Sorry but its not realistic to fix those two fatal flaws in one word document no matter how long and involved it is. If as a manager you feel the need to understand all that stuff then learn it yourself don’t burden your devs with your education. And whilst you are at it review how you see your role as a manger – perhaps you could just trust the experts in each area and actually ‘manage’?

Generally I think devs hate documentation because so much of it is pointless. At my last job my manager kept asking me for more documentation, I kept asking if they had read the stuff I had already done? No, was always the answer. Read it and tell me what you think is missing I would say in a groundhog day style weekly cycle.

how much do you like documenting your systems? recieving documentation on projects you take over? whats your definition of useful doco?

cheers

Simon

More blogging coming

A significant change in circumstances means I should have a bit of time for blogging, at least for the next couple of months.

I sacked my job off!

I had a really good job, working with nice people, using interesting technology to address important business issues. Then incompetent IT mismanagement got involved…

I’m not very good at doing pointless busy-work, especially when critical business problems that are trivial to fix are left whilst everyone focuses on write only documentation and MicroMcManagement issues like task lists, micro time recording, tick lists, etc.

So if anyone knows anyone looking for a business oriented developer who prefers delivering usable apps to documentation no one will read, give me a shout. I expect to work in collaboration with the eventual users, not conflict.

cheers

Simon