Free Republic
Browse · Search
Bloggers & Personal
Topics · Post Article

To: RogerFGay
In my experience, time is always the biggest factor. "They" want it developed yesterday. So "they" turn to quick and dirty programmers who have no problem re-inventing the wheel in 6 weeks. A cultural change has to take place in a company for people to recognize the benefits, both short and long term, of reusable code.

It took me years to teach co-workers and management that if we write it once, we test it once. Quality Assurance was always the bottleneck to releasing new sftware. We had so much spaghetti code that had to be tested that it impacted our release date by months, not weeks, every single time.

The key to success in changing the culture at my (former) company was to implement a suite of software tesing tools. Once the testers realized they could build (write) a set of tests and run it against the code over and over to their hearts' content, I had an army on my side. They began asking for reusable code so they could reuse the test harnesses they had already built.

I prototyped examples for the application developers and encouraged them to expand upon the ideas. Even the "quick and dirty" programmers began to catch on. I added extensive comments to my prototypes always making an effort to explain why more than what. "The user documentation explains what it does," I would tell them. "Use your comments to tell the next programmer what you were thinking and why you decided to write it this way."

The time it took to test and release software updates that included the reusable code decreased exponentially. Management was so impressed by the "time factor" that they began allowing us to rewrite sections of the spaghetti code with each new update/release. And what programmer doesn't relish the idea of rewriting some piece of crap instead of fixing it over and over?

Convincing the software testers of the benefits of reusable code was where I started. It was a huge success in my particular experience because they had always been the bottleneck. Removing that obstacle enabled more software releases in less time, which made management and customers ecstatic.

31 posted on 09/20/2010 11:07:04 AM PDT by BuckeyeTexan (There are those that break and bend. I'm the other kind.)
[ Post Reply | Private Reply | To 9 | View Replies ]


To: BuckeyeTexan
BuckeyeTexan: That's one of the best success stories I've ever heard. When I started reading the post, I was afraid I'd be disappointed with a longer sob story and just be responding to the first couple of sentences.

BTW: If I had, I'd have mentioned there's a big difference generally between project managers who have engineering experience and those who don't. The lines in my article about managers preferring rapid prototypers over good practice - and the one about this leading to longer more expensive projects producing lower quality is from experience. But then, I switched early from being a regular employee to an hourly wage consultant - ethical as I was, I'd try to talk to managers about the don't follow the "twinkle in your eye" ideas about good software - just hurry up and make things appear on the screen being a very bad idea - and after sincerely trying, would accept the situation which I knew would result in much longer contracts. In the world of project work, you have to be a team player.
40 posted on 09/20/2010 11:37:53 AM PDT by RogerFGay
[ Post Reply | Private Reply | To 31 | View Replies ]

Free Republic
Browse · Search
Bloggers & Personal
Topics · Post Article


FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson