Respect

There is growing appreciation of the fact that agile approaches are in fact just applied common sense. Recently I have also found it striking how many agile practices (and un-agile anti-practices) can be justified by the concept of respect. Some examples:
 
It is disrespectful to developers to impose arbitrary estimates upon them
It is disrespectful to customers to ask them to sign off requirements which they can not possibly understand
It is disrespectful to customers and developers to pretend that a paper-based design is anything other than speculation
It is disrespectful to everyone involved to suggest that an estimate for solving a novel problem in a novel way is anything more than a guess...
It is disrespectful to everyone involved to ask them to spend time writing, reviewing and signing off a document that will never be referred to again
It is disrespectful to team members to throw them into a situation without allowing them proper preparation and training
It is disrespectful to customers to sell them a team to whom you have done the above
It is disrespectful to blame or reward individuals when the system is responsible for 95% of their performance

...and so on.

Given Agile's roots in the Toyota production System, with its twin pillars of Respect For People and Continuous Improvement, this shouldn't be surprising, but I can't help feeling that more awareness of this aspect would help reduce the amount of Cargo Cult Agile that we are seeing.

Why Software Sucks

Earlier this year I enjoyed reading David Platt's 'Why Software Sucks', in which he discusses why software is regarded so poorly by so many people. It was entertaining, well written and contained a fair amount of wisdom. I'd certainly recommend it to anyone considering writing any software with a user interface.

I was reminded of the book today, when this masterpiece popped up on my screen (Click on it to see it full size):


I've read it several times now and I'm still not sure what it means. I'm pretty certain that I'm not likely to trust any site that asks questions like that. I'm also sure that I don't really trust the test and QA processes of any organisation that lets software like that out of the door.

To make matters worse, there is no way to tell this baffling and irritating dialog to go away. Choose 'No' and it will reappear every time you go back to the page that launched it.

It is always nice to have your prejudices reinforced (I'm not a massive Microsoft fan), and I did really enjoy the slightly theatrical rant I was able to have as a result. But my employer forces me to use this software, and I think I'd really rather they didn't, particularly when there are a number of open-source alternatives that treat their users with a little more respect.

P.S. I initially thought that it was another display of suckiness that it wasn't possible to tell Blogger to upload the picture of the dialog full size - but to do so would ruin the design of the page, so it's probably OK.

Quality Software Development - Science or Art?

In a thoughtful and well reasoned post on Sys-Con, Dirk Morris draws on the arguments in Zen and The Art of Motorcycle Maintenance to put forward the view that software development is both Science and Art. Rather more interestingly he suggests that Open Source tends more towards the science, and proprietary software tends more towards the art, citing Apple's OS X as the prime example - open source engineering at the core, with proprietary eye candy on top.

Blogged with the Flock Browser

Target-driven management

Once again, I am inspired by Simon Caulkin of the Observer. The context of his rant is the health service, but the lessons are far more broadly applicable. It's long been the case that you could trace the ills of most organisations back to the performance-related pay schemes of its managers, but the problem has got worse (at least in the UK) since our government's enthusiasm for 'proving' what a good job it is doing by 'meeting' targets.

In our business, I have seen many instances of damaging targets. I once worked in an organisation where it was decreed that we all should be given a target of contributing a certain number of pieces of 'intellectual capital' to the knowledge bases every year. Unsurprisingly the knowledge bases soon filled up with utter cr*p, but hey, we met the targets so the bonuses were paid. To deal with the quality issue, someone came up with a cunning plan - all contributions had to be rated by one's peers, and only those which had a high enough score would count. So a system of 'you rate mine and I'll rate yours' arose, the knowledge bases continued to fill with rubbish - and we continued to get our bonuses, effectively being paid for wasting the companies' money and time. Other instances are paying people a bonus based on bugs fixed, which leads to the deliberate introduction of easy-to-fix bugs and a nice little earner, or rating people by lines of code written, which leads to an orgy of cut-and-pasting.

Caulkin points out

if enough pressure is applied, people will meet targets - even if they destroy the organisation in doing so. As quality guru W Edwards Deming put it: 'What do "targets" accomplish? Nothing. Wrong: their accomplishment is negative.'

At a high enough level of abstraction, targets are fairly benign. It is when they are chosen just because they are measurable the damage really starts. They also usually encourage short term thinking, erode trust and therefore the feeling of personal responsibility for outcomes. Targets are set top-down, in advance - the management equivalent of waterfall development. Human nature being what it is, targets trump thinking - and if we've learned one thing about software development in the last 40 years it is that thinking generally helps the process.

The agile movement tends to avoid numerical targets in favour of more woolly but also more useful aims such as delivering value to your customer. My experience is that when we trust people to do a good job, and remove the obstacles to them doing so, the results are invariably superior than when trying to coerce that behaviour by the use of targets.

SOA still struggling

I don't want to be a luddite about this, but it has been apparent for some time that the hype about SOA was out of all proportion to actual implementation. I've formed this view based on talking to customers, partners and competitors about what they are actually doing, but this report seems to confirm my observations. Apparently,

Only 10 per cent of respondents believe that their business understands SOA 'quite well' and 22 per cent pointed to a 'medium amount' of knowledge.

and

A third of respondents to the survey have started to design and implement systems based on SOA principles, and a further 16 per cent are in the planning stage.

However, this still leaves a significant number of companies which have yet to embark on this route. Some 16 per cent are planning to look at SOA 'sometime in the future', and 23 per cent have 'no plans' to use SOA at all.

Since SOA has now been around for several years, but a very large proportion of the people who claim to have actually adopted SOA turn out in reality to have implemented a bit of EAI or used a couple of Web Services inside a single application, I think it may be time to ask whether it will ever deliver the goods.

Reality disrupting SOA sales effort

I’ve had conversations about the practicalities of SOA with various people over the past couple of years, and the gulf between what we expressed in relatively private forums and the public pronouncements was striking. It was apparent to most of us that the pre-requisites for successful SOA were significant, and unlikely to be present in any organisation we had ever encountered. It was also clear that there were huge challenges in delivering adequate quality of service from SOA-based systems.

For whatever reason, people seemed reluctant to express these concerns in public. Perhaps they didn’t want to kill the goose that might lay the golden eggs, or perhaps they just didn’t want to be seen to be out of step with the rest of the industry. Something seems to have changed, and the first items of dissent are appearing. The lead article in “Information Age”, March 2007 issue (not yet online - I’ll edit and insert the link when available), is called “Structural Hazard - The Pitfalls of Service Oriented Architecture” . The article discusses the difficulties of governance, infrastructure and culture, as well as the potential SOA has to make the organisation’s IT even more complicated, rather than simpler. Steve Jones, in his Service Architecture blog, points out the implications SOA has for availability, and also notes the potential for complexity. There are other examples - Googling for “SOA pitfalls” gives 691000 hits.

I don’t know what has prompted the new realism (perhaps people realised that the goose didn’t appear to be laying any golden eggs), but it can only be a good thing and will likely lead to a healthier relationship between the IT industry and its customers.

What's wrong with process?

Ivar Jacobsen makes some interesting comments about the value of process in a recent article on the Dr. Dobbs site. He is obviously setting himself up to introduce his new ‘Essential Unified Process‘ as the answer to the issues he raises in the next article in the series, but many of his points are nonetheless valid.

Of course, process blindly applied is unlikely to be useful, and process without underlying understanding of engineering good practice is of equally dubious value. Which is why my three priorities for my teams’ learning and development this year are:

• RUP - as a process framework, backed up by practitioners who understand how to use RMC to produce a process and a set of guidance that is sensible for the project


• UML - as a common language that allows communication between elements of the team with the minimum possible ambiguity and maximum clarity


• Construction - good practice as embodied in Code Complete, Steve McConnell’s seminal book on the skills, tactics and techniques needed to build quality software

All three elements, applied with intelligence and with the benefit of experience, need to be present to deliver a successful project. Oh, and a bit of luck too.

Hardware and Productivity

Developers working with modern IDEs like Eclipse, Team Studio or Netbeans need all the screen space that they can get. Martin Fowler points out the value of larger screens in his ‘Big Screen’ blog article, and states that his $700 investment in a pair of Samsung 204Bs could easily be cost justified.

In fact it gets easier by the day as Pricerunner tells me that today he would only need to pay just over $600. Unfortunately this translates to £600 in the UK :-(, but the Samsungs are high-end kit so if you were prepared to slip your standards a bit a 20″, 1650×1050 widescreen TFT could be yours for less than £150. You know it makes sense.

While I’m on the subject of hardware, when I began my IT career a gigabyte of disk storage cost about 10 times the annual salary of a junior programmer (as I was then). Today, the cost of a gigabyte of disk is roughly a minute of a junior programmer’s salary, leading to the conclusion that the storage for our 50MB Outlook Inbox is worth three seconds of their time. Perhaps it is time to revisit the cost/benefit assessment for that particular limitation…

Open Source Quality

It has always been said that the openness of open source led to higher quality code, because there were more pairs of eyes looking over the code, and because if they found a problem they could fix it rather than having a depressing conversation with first line support.

As far as I know, there has not been much actual research to prove this point, it has been more like an article of faith for the Open Source community. But the Register reports that Fortify Software (which uses Fortify SCA tools and Findbugs to look for defects in software – as a service) are finding some very low defect rates in popular OSS applications. You can see the results at the Open Review pages.

The relevance for us as developers, apart from confirmation that using OSS does not necessarily represent a technical risk, is that the principles espoused in Builder.com’s 10 Commandments of Ego-lesss Programming really do lead to higher quality. For what is OSS if it isn’t a comprehensive implementation of those commandments?

Interoperable Acquisition

At the tail-end of last year, the SEI (Software Engineering Institute) published a paper on ‘Interoperable Acquisition for Systems of Systems‘. Although it has a defence slant (the SEI is largely funded by the US military), there seems to be some considerable relevance for organisations interested in adopting SOA and/or a multi-sourcing model for their IT systems. I struggled through the paper, wincing at the callous mangling of the English language*, only to find that the conclusion was that governance around the procurement, construction and operation of ‘Systems of Systems’ was really hard and the authors wanted more research funds to figure out the solution to the problems. Contrast this with the current hype around SOA as the solution to all an organisation’s IT issues. So the message for us is that we should be careful about diving in to the SOA pool, particularly about what we promise our customers, and that wherever there is uncertainty, there is a consulting opportunity

*The most painful being the use of ‘fielded’ when they appeared to mean ‘deployed’ or ‘in use in the field’. I hate it when they verb nouns like that.

Essential Reading?

Reg Developer just asked the question "Do you own these bookshelf must-haves?". Clearly, they just want to boost their associate fees from Computer Manuals, but it is an interesting topic for discussion. I own a few of them, although my copy of Petzold is a bit out-of-date. I've always wanted a set of Knuth's books, but when I put them on my Christmas list I generally get told I'm being too 'sad', whatever that means. What about you?

Software Development should be fun

Like a lot of people my age, I got into what is now called the IT business because I really enjoyed programming. We didn't really consider the money side of things, or whether it was a long-term career, we just liked messing around with computers. If people were going to pay us for it, that was even better. The word 'geek' came later...

David Intersimone, now Vice President of Developer Relations and Chief Evangelist for Borland Software, has an article on the Dr. Dobbs site called "Why Programming is Fun", which reminded me how I got started. But it isn't just nostalgia for me - I think we need to bring some of that attitude back. I know the last few years have been hard, and projects today are more challenging than they ever were 20 years ago, but these things do not preclude enjoyment. David's article quotes 5 reasons why software development is fun from Fred Brookes legendary "Mythical Man Month":

• The sheer joy of making things.


• The pleasure of making things that are useful to other people.


• The fascination of fashioning complex puzzle-like objects of interlocking moving parts.


• The joy of always learning.


• The delight of working in a tractable medium.

I don't see anything in that list that is less valid today than it was when Brooks wrote it. A critical part of my job, and the job of our sales teams, is to make sure that those aspects of our work are not overshadowed by less positive influences.

Bad Code

The "Bad Code" posting on Wired's 27B Stroke 6 blog is both funny and sad. I can't add much to it, just go and read. If you aren't a coder, a little bit of background research might be needed, but it isn't too hard.

Software developers 'abandoned' by management

I think I'm getting kind of obsessional about poor quality and the choices our society is making. This article at vnunet is yet another example of how the current obsession with low price as the only differentiator in fact leads to lower quality of life and higher real costs for most of us. I don't think, in 20 years in the industry, that I've ever worked in a software development organisation where management saw quality as an important aspect of their job. Price, and schedule were the main drivers. Quality was 'what can we get away with?'. I don't blame the managers - the reality is that no-one is demanding quality as their priority measure, so in our market economy we get what the market demands which is 'faster, cheaper'. But as the old saying goes: "you can have it good, cheap, or fast - pick any two". As a developer it is depressing to be constantly pressured to release code that you aren't happy with - and as a customer, it's pretty depressing to pay for buggy software. But that seems to be the choice we have made as a society.