Hawaiʻi's Technology Community

IT Development improvements - improving quality, decreasing bugs, reducing development time

Hey techhui members out there. I'm the development team lead at the Bank of Hawaii and one of the things on my mind is ways that our team can take our development processes to 'the next level.'

Internally we have several standard source control libraries that we include in most of our projects that help reduce our development time. We have internal applications that help to automate our deployment process to our production environment, and we use an iterative development process to develop applications. But where do we go from here? How can we reduce the number of bugs that make it to a production environment, how can we better catch and log errors (especially when users don't report them?)

I'd like to find out if there are any other Techhui members out there that would like to get together to share their challenges and development best practices. It could be a forum discussion, a panel, whatever. I don't necessarily expect that the discussion would be technical in nature, and I wouldn't expect anybody to share 'competitive advantages,' but it would ideally be an opportunity for people in different development environments to exposure to what other teams do and to share what works for them with the goal of simply sharing ideas and development practices to become better developers.

I'd love to organize this with anybody else that is interested.

▶ Reply to This

Replies to This Discussion

Permalink Reply by John Higuchi, PMP on April 15, 2010 at 10:44pm

I'll offer some insights and advice to your quest to improve your IT development efforts.

Improving quality: 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.

Decreasing bugs: 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".

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.

Reducing development time: 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.

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?"

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.

I suggest that you or others start looking into Agile Software Development process. It has helped in my development efforts over the years.

Quoting wikipedia:

Some of the principles behind the Agile Manifesto are:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily cooperation between business people and developers
* Face-to-face conversation is the best form of communication (co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

Wikipedia Link

I hope this starts the discussion.

▶ Reply

Permalink Reply by Andy Sabo on April 16, 2010 at 10:09am

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.

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.

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.

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.

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.

Anyway, here are some links to some interesting points of view on Agile and other processes:

http://www.agiledata.org/essays/differentStrategies.html#SeveralMet...

http://www.osait.com/knowledges/development-process/waterfall.html

http://foohack.com/2007/11/agile-scrum-sucks-but-so-do-the-alternat...

http://www.rallydev.com/agileblog/2009/08/an-alternative-to-agile-a...

http://www.cmcrossroads.com/index2.php?option=com_content&do_pd...

http://www.softwareresults.us/2010/03/alternative-agile-triangle.html

IT Development improvements - improving quality, decreasing bugs, reducing development time

Replies to This Discussion

Sponsors