How can we make the software development process better? Many things seems obvious, but little has been done to thwart this age-old dilemma. I don't really think I have any "silver bullets" to this problem, but I do offer three possibilities below:
Silver Bullet 1: Change Things Up!! Incentives??
Too many times I have been on a typical project (typical for my organization) and before it even begins the programmers (and most of the others on the project) are already digging their heels in for months of work. Why does it have to be this way? Why does this project really need to take 3 months? I'm sure if we analyzed the actual amount of work that needs to be done, it will usually be less than that, but in actuality it will probably take longer than that. I think there needs to be a shift in thinking. I think too many people are complacent and even "lazy" if you will. If they can get by with doing as little work as possible during a day, but still get enough done to progress the project forward, then that's what most would do (heck, I'm guilty of it). Maybe if there was more of a "financial incentive" people could shift attitudes and really go that extra mile to get the project done. If I keep my job whether I get this project done on-time and on-budget (or not) what is the incentive for me? I will just do my part of the project and let someone else worry about the rest. If someone was going to give me $1000 bonus to finish my part in 4 weeks instead of 6, perhaps I would consider doing that.
Silver Bullet 2: Hold programmers more accountable (more design docs)
I think that many programmers get away with high estimates because not a whole lot of people can understand what they do. The business folks don't want to worry themselves with all the technical jargon, so they usually take the programmer's word for it and don't question first, second, or third level estimates. I know in my organization the programmers do not (and really aren't even required) to create design docs on what they build. They just build programs that nobody understands but them. And when it comes down to makes changes later on, the effort is costly and time consuming because no one knows how the program works to begin with (and what if the original programmer is no longer with the company)? Design docs could help all to better understand the program, and allow for more realistic changes and upgrades later.
Silver Bullet 3: Bring back coding on-shore!!!
I think the author of the article had it right, experienced and knowledgeable programmers are really worth their weight. I can't tell you how many times that I have worked with offshore programmers that don't understand a thing about software development. They have usually never coded before and just don't understand our businesses enough to be successful. I'm not knocking the whole model (I know that some organizations have had success with it), but how long did it take before that success was reached? Do these organizations go back and analyze the cost differences in the two models to see if there really was a savings? Or do they just look at the bottom line (i.e. paying US person $100/hour and paying offshore $50...no brainer). There are so many other things to consider. Are your projects taking twice as long to complete? Is the code being churned out more buggy? Are there corners being cut in other places? Testing? Design? You have to look at the whole package.
Like the author said, there really is no silver bullet. But trying new things to find a method that actually works for your organization is better than just sticking with the same old method that has been losing your company money year after year. Maybe adapting/changing is the silver bullet, or as close to one as we can expect.
No comments:
Post a Comment