IT Development improvements - improving quality, decreasing bugs, reducing development time - TechHui2024-03-28T11:14:56Zhttp://www.techhui.com/forum/topics/it-development-improvements?commentId=1702911%3AComment%3A61399&feed=yes&xn_auth=noGood idea Matthew, the only w…tag:www.techhui.com,2010-05-14:1702911:Comment:613992010-05-14T20:53:21.329ZNaim Fergusonhttp://www.techhui.com/profile/JoeFerguson
Good idea Matthew, the only way to improve process is by constant scrutiny.
Good idea Matthew, the only way to improve process is by constant scrutiny. As software developers, we li…tag:www.techhui.com,2010-04-16:1702911:Comment:599322010-04-16T20:09:29.145ZAndy Sabohttp://www.techhui.com/profile/AndySabo
As software developers, we like to wrap solutions to problems up in a simple step-by-step process. Unfortunately, the world doesn't work that way. I have been doing this for 30 years and have met so many SW Engineers with this thought process.<br />
<br />
Every company is different; the development process needs to fit management's expectations, considering the level of talent, teamwork, diversity of skills, and history. I worked at BOH before with managers that did not keep up with new technology.…
As software developers, we like to wrap solutions to problems up in a simple step-by-step process. Unfortunately, the world doesn't work that way. I have been doing this for 30 years and have met so many SW Engineers with this thought process.<br />
<br />
Every company is different; the development process needs to fit management's expectations, considering the level of talent, teamwork, diversity of skills, and history. I worked at BOH before with managers that did not keep up with new technology. Understanding the history of the organization, past decisions, company objectives and goals, and learning from past mistakes should be evaluated before deciding on application of a standard SW Dev process to manage [direct] a project or program. It is like directing a movie; there's a technical and creative aspect. Keep in mind that your efforts will become part of that company history. I know it's deep, Brah.<br />
<br />
I was recently asked in a SW Management interview about my opinion of Waterfall vs SRUM development. As soon as the guy started asking the question, I knew I didn't want the job and was looking at the door. Agile is not wrong, it's just not always right.<br />
<br />
At Seagate [many] years ago, they sent me to school for Statistical Process Control and demanded that all Engineers use SPC in all engineering processes, including hardware, software and firmware. For the next 5 years we lost market share and missed many opportunities to develop new products. We had an internal focus like an ostrich with his head in the ground. Our stock prices plummeted, but the [old] products had improved quality.<br />
<br />
Quality in software comes at a cost: talent, time, tools, technology, and testing. Hey, the 5 T's... (just made that up). The most important element to me is creativity and looking at alternatives to avoid recreating the wheel. I know banks need to protect information, but that doesn't mean that all work should be done in-house.<br />
<br />
Anyway, here are some links to some interesting points of view on Agile and other processes:<br />
<br />
<a href="http://www.agiledata.org/essays/differentStrategies.html#SeveralMethods" target="_blank">http://www.agiledata.org/essays/differentStrategies.html#SeveralMethods</a><br />
<br />
<a href="http://www.osait.com/knowledges/development-process/waterfall.html" target="_blank">http://www.osait.com/knowledges/development-process/waterfall.html</a><br />
<br />
<a href="http://foohack.com/2007/11/agile-scrum-sucks-but-so-do-the-alternatives/" target="_blank">http://foohack.com/2007/11/agile-scrum-sucks-but-so-do-the-alternatives/</a><br />
<br />
<a href="http://www.rallydev.com/agileblog/2009/08/an-alternative-to-agile-adoption-cookbooks-flow-pull-innovate/" target="_blank">http://www.rallydev.com/agileblog/2009/08/an-alternative-to-agile-adoption-cookbooks-flow-pull-innovate/</a><br />
<br />
<a href="http://www.cmcrossroads.com/index2.php?option=com_content&do_pdf=1&id=6760" target="_blank">http://www.cmcrossroads.com/index2.php?option=com_content&do_pdf=1&id=6760</a><br />
<br />
<a href="http://www.softwareresults.us/2010/03/alternative-agile-triangle.html" target="_blank">http://www.softwareresults.us/2010/03/alternative-agile-triangle.html</a> I'll offer some insights and…tag:www.techhui.com,2010-04-16:1702911:Comment:599202010-04-16T08:44:17.400ZJohn Higuchi, PMPhttp://www.techhui.com/profile/JohnHiguchiPMP
I'll offer some insights and advice to your quest to improve your IT development efforts.<br />
<br />
<b>Improving quality:</b> This is the holy grail of development and the hardest to achieve since its subjective. From the client, to project manager, to designer, to programmer and so on its different from person to person. Improve from what is the question i would ask first. Define the clients requirements to a point that you, your team, your management, and your mother can understand. Write the…
I'll offer some insights and advice to your quest to improve your IT development efforts.<br />
<br />
<b>Improving quality:</b> This is the holy grail of development and the hardest to achieve since its subjective. From the client, to project manager, to designer, to programmer and so on its different from person to person. Improve from what is the question i would ask first. Define the clients requirements to a point that you, your team, your management, and your mother can understand. Write the requirements in such a way that a person off the street with little or no IT development expertise would understand. The clearer the picture, the clearer you will understand what the client is expecting and paying for. Quality is then determining how close are you to creating that picture. Avoid goldplating.<br />
<br />
<b>Decreasing bugs:</b> Decreasing bugs is an inverse of # of times you test the application/feature/functionality. The XX times you test the better you and your team will be at meeting the client expectations and your own level of completeness. Test the application like you want to break it. If you break it then you found the bugs; others call this "Gorilla Testing".<br />
<br />
Be honest - The team and the Project Manager must be truthful what the application can and cannot do then convey it clearly to your client. If you are supporting the application over a lifecycle then you have the ability to declare bugs in a known bug list. I find that bugs is not such a bad thing. No program or application is never bug free. The critical issue that stops the train is not to have applications errors or crashes - error handling is your friend.<br />
<br />
<b>Reducing development time:</b> Reducing development time is not a good thing if you throw quality and functionality out the door. The balance is to meet the clients expectation as to the acceptable quality level. You stated you are following an iterative development process which is good but hopefully you are involving the cllient and stakeholders into the review. I have found that an Iterative development process is more for the client then it is for the development team.<br />
<br />
By develop in smaller increments it greatly helps the development team (build, confirm, build, confirm, build, confirm) and lowers client doubt in your development time estimates. We all heard clients say one time or another, "does it take that long?"<br />
<br />
Why are you reducing development time? Do you not trust your development team, you question the compentency level of a team member or do you not uderstand how long it takes.<br />
<br />
I suggest that you or others start looking into Agile Software Development process. It has helped in my development efforts over the years.<br />
<br />
Quoting wikipedia:<br />
<br />
Some of the principles behind the Agile Manifesto are:<br />
<br />
* Customer satisfaction by rapid, continuous delivery of useful software<br />
* Working software is delivered frequently (weeks rather than months)<br />
* Working software is the principal measure of progress<br />
* Even late changes in requirements are welcomed<br />
* Close, daily cooperation between business people and developers<br />
* Face-to-face conversation is the best form of communication (co-location)<br />
* Projects are built around motivated individuals, who should be trusted<br />
* Continuous attention to technical excellence and good design<br />
* Simplicity<br />
* Self-organizing teams<br />
* Regular adaptation to changing circumstances<br />
<br />
<a href="http://en.wikipedia.org/wiki/Agile_software_development" target="_blank">Wikipedia Link</a><br />
<br />
I hope this starts the discussion.