cam, 235 words, 0 comments, Software Projects, CSS, Customers, Software, Quality

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)

cam, 176 words, 0 comments, Technology, Software, Web Technology

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)

cam, 757 words, 0 comments, Software, Software Development, Business Models, John Barrdear, Code is Law

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)