'Software should not be built like Model T Fords'

By: Ray Pellecchia

File Under: NYSE

• 1 Comments
• Email Entry

Our post on Monday, CEOs: people are key, but tech is under-delivering, was a NTDWH entry (Nothing To Do With Hybrid) but produced a spike in readership (that is, larger than my immediate family). So playing to the audience a bit, just wanted to point out that a couple of people have commented on that post, including this comment posted earlier today by Steven Rubinow, NYSE Group's chief technology officer and executive VP:

In the just released NYSE CEO Report 2007, one theme that stands out for technologists is the that of the partially unfilled promise of technology. A mere one-fourth of CEOs claim the ROI of their company’s technology investments have fully met or exceeded their expectations while an almost equal proportion say the ROI on their investment in technology has fallen short of their expectations. Since ROI has a benefit and a cost component, here are some observations on how to get ROIs more in line with expectations by increasing benefits and/or reducing costs:

Be involved, really involved.
Senior management shouldn't abdicate their responsibility in critically questioning strategies, projects, benefits, costs, etc. Too many view this subject as "rocket science" and defer to the technology "expert" they've hired. This "expert" - CIO. CTO, consultant, etc. may be excellent but can be too close to the subject matter. Fresh perspectives/questioning from other non-technology management can yield valuable insights. I remember a Fortune 500 CEO I made a presentation to who stopped me at the first PowerPoint slide and said "Whoa, remember I was only a history major" and told me that I could go ahead with the project even though he had not asked one question. I appreciated the vote of confidence and the project was successful but I would also have welcomed some more critical review. I am a big proponent of thinking like a start-up - if I had limited resources and limited time, would I do this project the same way? Is there a more creative approach I could take that would deliver most of the value at a lower cost and in a shorter time? Ben Franklin said "Necessity is the mother of invention". I think too many companies aren't sufficiently "needy" to become inventive.

Software should not be built like Model T Fords
Too many firms have a modern version of the automobile assembly line for software. Business analysts give their requirements to a systems analyst who then gives it to a development manger who gives it to a project manager who gives it to a number of developers and tech writers and operations staff, etc., so that in no time we have yet another example of the "Mythical Man-Month" effect. Each person in the assembly line has their pre-defined box whose limits they are supposed to work within. A better model is to assign multiple roles to a smaller number of people, people who can do several jobs well. Gartner has coined a term for this - the versatilist. This kind of job strategy provides greater value to the firm and higher levels of job satisfaction to the employee. Many firms have a quick fix for the assembly line cost - they move it offshore so they can do the inefficient process at a lower cost. Offshoring should be reserved for either very well understood problems (e.g. accounting systems) or for severe resource shortfalls. Moving inefficient processes to a cheaper venue is merely a band-aid. One other thing to keep in mind is that productivity of development projects is inversely proportional to the distance between all the stakeholders. Have all the business and technology folks in one big room - highly productive. Separate them by floors or buildings - watch the productivity decrease. Increase the distance to thousands of miles - well, you get the idea. This proximal packing configuration may not always be practical, but you should be mindful of it should it be possible. I always got a laugh out of the early Internet retailers and service providers who proclaimed the end of the shopping mall because it would be replaced by cyberspace locations, totally discounting the social patterns of humans whose needs and habits have been evolving for many millennia and aren't easily replaced by a 19" monitor. The same principles apply to the workplace.

Folk wisdom: "Two heads are better than one" but "too many cooks (engineers) spoil the broth (system)"
I am a big fan of simplicity in systems. Simple designs are cheaper and faster to build and easier to support. Complexity is the enemy of reliability. Projects that have a large staff tend to be overengineered - all the very competent people on the project need to have their contributions incorporated in the project because that's how they're compensated. The result - very busy Visio diagrams highlighting everyone's contribution to complexity. The war in Afghanistan was essentially won by a very small number of highly qualified soldiers. Believe in the power and ability of small teams.

Productivity?
Speaking of productivity, don't fall for the productivity trap as a justification for projects. So many times I have heard that if we do "this" our staff will be significantly more productive. Who can argue against increased productivity? But if the net effect of the technology project is to allow the work that was not enhanced by this project to expand to fill the newly found time, then there has been little or no productivity increase. If you can't measure this productivity increase in head count (either reduced or not hired) then make sure you have a valid program of measurement to see if there really was a productivity gain.