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'. (reply)
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. (reply)
Douglas Crockford, "JavaScript's popularity is almost completely independent of its qualities as a programming language." (more)
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. (more)
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. (more)
Cam Riley: South Sea Republic. Freedom, liberty, equity and an Australian Republic.