John Barrdear has an interesting comment on IT and how it often introduces inefficiencies into a business process. He writes:

In practice, I have seen two other phenomena that both work to increase bureaucratic staff numbers:

a) IT tends to make work practices quite rigid. ...

b) IT projects, at least in the public sphere, are rarely implemented (or, frankly, designed) well. This seems to exacerbate the problem in point (a).

I tend to split software projects up into two possible sections; ones that have to take into account a dynamic business model, and those that are for a static business model. They require different software approaches.

The static business model is one where the requirements can be written out, then they can be handed off to some designers to be estimated, and then commodity labor - probably in India - can be used to write software to the APIs or interfaces.

Because it is a static system there is not that great an issue of it is late or overly complex. Testing can also attract large resources as the system will be in production for a long time simply because the business model is not moving at all.

As an example a friend of mine works at the federal reserve in DC. A lot of their systems are written in COBOL and run on mainframes. The issue they are facing is that much of the skilled labor required to run these systems are retiring. The only reason they are updating them to C# is because the labor is getting to expensive to run the old ones. Not because the old systems are not working or don't reflect the current business process.

The flip-side to the coin is the dynamic business model. In my opinion and experience this is the fun part of software design and development. It is also the most stressful and full of pitfalls.

Because of dynamic business requirements that change constantly over time as new challenges from existing customers or future markets are met, the software cannot be designed as a static system. In the six months of requirements collection, nine months of design and year of development overseas a dynamic business has a new business model and process. The software lags behind and enforces inefficiencies in the system.

Consequently it requires a different approach. The Agile Methodology is a response to this. I personally like Alistair Cockburns production philosophy that minimises development process such that it meets customer quality control requirements. Anymore is overhead and imposition.

One of the components of Agile Methodology is unit testing. This is done to meet quality control requirements. For instance Space Shuttle software will have a 100% test coverage. A social networking website may only have 5% test coverage. It depends on what the customers will accept.

There is an analogy between software development and law. Artur Bergman mapped and visuallised several systems of code and law to determine if there was a pattern.

Bergman writes:

Quite clearly, we can see that US Code is appropriately named since it has more in common with kernel32.dll than the contents of Project Gutenberg. Not only is code law, but law is code: a highly structured set of instructions that allows a state machine to function, ideally without any ambiguity.

It is probably not a surprise that SSR is heavily haunted by software developers and technologists. There appears to be a natural union between software code and legal code.

We can also divide the legal world into static and dynamic. Where the static is the constitution which has a slowly moving business model and process. And the dynamic component is statutory legislation. Far more volatile and requires greater customer input and quality control. There lies the rub, our quality control in legislation is constitutional constructs such as separation of powers and checks and balances.

Not direct unit tests however; Andrew Leigh and Justin Wolfers have argued for policy testing:

Why don't we see more randomised trials in Australia? One impediment is a cultural attitude that government services are an entitlement, and therefore must not be rationed. Yet it is time that this conventional wisdom was balanced against the benefits that can flow from careful pre-testing of government programs.

The easiest step to take is to open ABS data to citizen auditors and stop charging for it. The cost to the taxpayer is an extra seven million. A spit in the ocean compared to the electoral bribes that will be handed out this year.

Roger Johannson writes on the lamest excuses for not being a web professional. One of the things that surprised me going from the US East Coast telecommunications world to the US West Coast dot-com world was how much of a rarity front-end developers are. Middleware is a well traveled and understood problem domain. The front-end has several new technologies and has not commoditised as the middleware and back-end has. For instance, front-end MVC frameworks are a rarity; they are as common as dirt in middleware.

What the company I am now with calls the "presentation layer" actually delves into what I would call Middleware, going a bit deeper than the controllers. Which means what they call a front-end developer has to be aware of technologies from Java, HTML, Javascript to CSS.

CSS developers are the real rarity and in a development process that is driven by the User Experience group they are the most essential. It has been interesting to see what I thought was important get turned on its head by a different industry.

That is a good thing for anyone who works in the web world and has to get CSS and even Javascript to work with Internet Explorer. Older versions of Safari are less hassle than IE. From the article:

ComputerWorld is reporting that Firefox is set to hit 20% market share next month according to metrics firm Net Applications. In some communities, Firefox is already well beyond the 20% mark. W3Counter's global web stats, for example, puts Firefox usage at closer to 29% and over 50% of ReadWriteWeb readers use Firefox.

Internet Explorer's popularity peaked in 2003 or 2004, depending on whose data you look at, with a browser share of between 91% and 96%. Now, IE's market share has slipped below 80% by most metrics. Firefox, meanwhile, has grown steadily year-over-year from under 1% in 2004, to around 20% today.

It is well deserved. Firefox is an outstanding product.

The Object Literal syntax is extremely powerful and expressive. Having functions as top level objects is not new, but in Javascript and the web it allows you to hitch a function to something out of scope. Which is very useful for callbacks.

I pretty much spend 90% of my time working in a product line that is part javascript framework, part javascript re-usable components and totally object oriented. I have seen the power of javascript up very close and have a lot more respect for the language now.

Added bonus is that I am exceptionally comfortable in it too as a result of having to work out complex problems, both business and softwre related, in the language.

We are at the stage in the project where we no longer own the code. Ownership is now with QA is it goes through a series of test environments on its way into production. Our customer is QA and their accounting mechanism known as bugs. Anything that does not match the spec, or customer expectations will be ruthlessly, and rightly, entered as a bug. As a consequence the code repository exists for satisfying those demands.

Via gui.tavares on flickr

We changed our view of quality for this project, incorporating the visual demands as an essential and integral part of the quality process. Previously we scheduled time at the end to do it all and due to the inevitable engineering pressures some of it squeezed out the wrong side of the project - ie was omitted.

The developers that were better at CSS produced high quality components, whereas those that were weak produced decent ones visually. CSS is not my strong point, unfortunately I am more the developer, but this was the reason for focusing on the visual side of things early on - otherwise developers just do code and algorithm and aesthetics are an after-thought.

From the customer's point of view though it is the first thing they see and the first impression they have of the product. Hence the focus on visuals and aesthetics early on in the quality process.

I have a saying, "Projects always win." It does not matter how you manage them, or how you approach them, the inherent stress and difficulty in bringing a project to production leaves physical after effects with the team; psychologically as a team and physically as individuals.

I recall many years ago doing a project in telecommunications where I was working between eighty and one hundred hours a week for an extended period - the dreaded software 'crunch'. Because it was all billable I billed every hour to the client. My paycheck each fortnight was 2.5 times what it normally was and I thought I was rich; however as soon as it went into production my body gave out and I was sick for the next two weeks. Projects win.

More recently we did a project that had us doing eighteen hour days through the QA period to production; I survived it better than normal due to my fitness regime but I was tired, like a robot, and carrying cold sores at the end of it. For the software team it took two months to shake off the tiredness effects of the project. There is a significant loss of productivity during that period.

The toys always come out at the end of the project and it is a way that we make up for the damage we do to our physical health. I bought my second Corvette the day my energy project went live. I was antsy the whole time during the purchase process as I was waiting for a doom and gloom phone call about it being in production and something going wrong. I can recall the car salesman being confused about my behavior.

My current Corvette I bought at the end of the Gravy Project for the same reasons. That team at the end of the project bought Corvettes (me), Lexus', House', Lotus', etc. The psychological desire to buy a toy or an extravagance of some kind at the end of a project is undeniable. It is how we keep ourselves up for the next project. Otherwise the stress is not worth it.

I recently read Sharon Moalem's Survival of the Sickest. In the back of the book he makes the comment to a question that the field of Psychoneuroimmunoendrocrinology [PNI] has sprung up to study phenomena such as why the body gets sick after a particularly stressful time. Moalem writes:

They [PNI Scientists] realize that from moment to moment every emotion we have is registered by most, if not all, of the cells in our bodies.

It is a reductionist view of emotions, but given my empirical experience with software projects, IMO, one that will bear fruit. Modern project management, even when done well such that there is no crunch period, or abject stress on team members (which is possible our last project was done on time and with the standard working week) still leaves physical and psychological residue on the team. It will be interesting to have that kind of effect mapped to immunology and the other physical medical sciences. It might even be able to answer why 'projects always win'.

Via coding horror, quote of a quote: "the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent."

I would agree on that anecdotally. One of the reasons we don't do them is time normally. We are just so strapped for resources, and over worked to an extent, that once one thing is finished, it is on to the next. The rhythm allows little space for doubt or reflection unfortunately.

I disagree with the effectiveness of design reviews. We treat them largely as proof that the team is ready to start on a project. Once the project starts coding no-one looks at the design document again. The review process moves who the customer is as well.

The document ceases to be for the team, and the customer becomes the reviewers. As a consequence changes are made to the document by the team simply to get the reviewers off their backs and so they can have the design signed off on and can start coding.

Cynical? Yes, but the truth in how this all operates.

One of the issues we are facing is an expanding product line that the team is responsible for. Despite a heavy QA focus and support, I consider it our responsibility to deliver high quality code at all times. As a consequence QA is my customer for working code within our structure.

But a growing product line within the one creation path places pressure on this process. For one change deep down, we now have seven different products paths we have to test to ensure that we don't muck something up. This is only getting larger as well; we are publishing a new product next month, and embarking on a larger product which will add more products. Which will add new challenges.

As hulver notes, however, and continuing on from the opening quote, sometimes you do have to step away from the keyboard, and get explain your code structure to someone. I agree that it does improve the quality of the code.