Seven practices for healthier, faster software development

Remove hindrances on even the most complex projects

Skill Level: Introductory Ezequiel Cuellar (ecuellar@atsva.com) Senior Systems Programmer Advanced Technology Systems

27 Jun 2008 In this article, learn about seven practices that can reduce overtime, cut costs, and speed up production on your software development project. Create a solid foundation for healthier development, and increase your chances of meeting deadlines with less stress.

Introduction
Software development is a human activity and, fortunately for us developers, it will be for many years (and maybe decades) to come. Unfortunately, as with any human activity, software development is prone to human error. History has taught us that human errors in a group working together can be minimized with organized collaboration among participants. Modern software development processes target collaboration by defining clear roles, activities, and artifacts on a development team. No matter how well an organization implements a software development process, or how much money it spends on the latest IT infrastructure and tools, I continually see the same problems that add overtime to a project and put it at risk of missing the delivery date. For example, consider how many times you have: Been stuck waiting for a database request to be implemented. Waited half a day or more for a business decision to be made.
Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 1 of 11

developerWorks

ibm.com/developerWorks

Been delayed after realizing that you haven't mastered the learning curve of a new programming library. Spent precious time trying to find a workaround for a bug in your recently upgraded integrated development environment (IDE). Spent time training the new development team member. I've contributed to many projects for different industries and have seen how several organizations deal with the challenges of creating complex software projects. I've observed how each project was managed differently, how problems were addressed, and what mistakes and achievements were made. The practices discussed in this article are based on my observations. These practices will help any software development team as they come up against common obstacles. They will also contribute to a solid foundation for healthier development and help speed up production. The seven practices are: 1. 2. 3. 4. 5. 6. 7. Improve business processes before starting development. Create a solid software development team. Improve processes for service requests. Minimize reporting of software metrics. Improve communication with the business team. Use the right programming language. Use the right IDE.

The practices in this article target problems that are better addressed at the management level. Usually, developers can only report the issues to upper management for consideration. Because project managers have the necessary level of authorization, they are the ideal candidates to promote these practices within the organization.

Improve business processes before starting development

The business processes in your organization might have many unnecessary flows or flows that haven't been properly standardized. Some flows may work based only on the experience of the staff in charge of their execution. Typically, staff in some departments know how to execute the tasks pertaining to their role very well, but

Seven practices for healthier, faster software development Page 2 of 11

Copyright IBM Corporation 1994, 2007. All rights reserved.

ibm.com/developerWorks

developerWorks

might not be familiar with the rest of the process outside their department. It is hard for them to collaborate with suggestions and improvements to the process. Software development is driven by requirements derived from the business process being implemented. If the business process hasn't been properly standardized or reengineered before software development starts, many questions will arise. Late questions could lead to important business decisions being made under pressure when you're trying to deliver the correct information to your development team on time. Software development and business process reengineering (BPR) cannot happen in parallel. Trying to make them happen at the same time will definitely result in delays and budget issues. The worst time to review the business process is in the middle of any software development phase. For example, consider two of the most critical phases: Elaboration If you reengineer a process flow that is being analyzed during the elaboration phase, there will be a delay in the delivery of written requirements to the software development team. It could also force the review and adaptation of previous requirements that might have already been delivered for implementation. Construction If you reengineer a process flow that was implemented in the software during the construction phase, the developers will have to readapt, or even worse, rewrite all affected software modules. Modern software development processes promote acceptance of change. But radical changes in direction can greatly discourage developers, especially if delivery dates are not adjusted realistically to accommodate changes. If you decide to develop the software implementing the business process as is, without checking for flaws or properly standardizing or reengineering, then the final software product will eventually reflect these flaws as well.

Create a solid software development team

One of the best assets an organization can have is a solid software development team with a long history of collaboration. Gone are the days when software was created by a single developer. Complexity in software projects requires the organized collaboration of several developers to deliver a product on time and within a budget.

Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 3 of 11

developerWorks

ibm.com/developerWorks

Mature collaboration on a software development team can't be achieved overnight. Nobody should believe that a software development team is composed of "just programmers" who are interchangeable and can be rotated to other teams. A team must have a level of stability that is achieved through long time collaboration by the members. The longer your team works together, the better they will perform. Developers with seniority can't be replaced like Lego pieces with new-hires, regardless of their experience. You want to encourage permanence among your team members. Just as you'd motivate an all-star basketball team, you need to motivate your your developers to be part of the organization. Things to consider are: Paying well Pay your developers well relative to the size of your organization and the return on investment of their work. Also offer yearly salary raises based on professional improvement that has benefitted the company. Remember, your software developers are not just programmers. Offering a clear career path Even with a good salary, many software developers tend to resign from their jobs if no clear career path is available. Carefully assess the goals of each member of your software development team. Some people will want to be promoted to management positions, and others will prefer to stay on the software development path. Whatever the case, clear career paths must be present and part of the company culture. Rotating roles on each iteration Challenge your developers to play different roles on each project iteration. Each team member will get the opportunity to have different levels of responsibility, become more versatile, and never fall into a routine. For example, challenge a developer to lead the whole team on one iteration, the next time have that developer do requirements analysis or software design, then move to deployment, testing, or documentation. Rewarding professional achievements outside work If a software developer writes a book or technical article, achieves a professional certification, or gains a skill that can be used in the interest of your company, that developer's effort should be rewarded. Offering professional training When possible, invest in your team by keeping their skills sharp and up-to-date. Focus especially on training that can provide a competitive advantage to your
Seven practices for healthier, faster software development Page 4 of 11

Copyright IBM Corporation 1994, 2007. All rights reserved.

ibm.com/developerWorks

developerWorks

organization. Maintaining a policy of "no overtime or working on weekends" Software development is closely tied to the developer's concentration and emotions. A bad piece of software can be the product of working in the wrong conditions or environment, such as working too much overtime or on weekends. While working overtime, I focused more on finishing the tasks quickly so I could leave, rather than on producing quality code. The situation is compounded if required information is delivered to you late, and whoever was responsible for it has left for the day. Focusing on progress more than hours worked Unless your organization profits by charging developer time, it's more important to focus on progress each day and delivering on or before due dates, rather than closely monitoring that developers fulfill their daily eight hours.

Improve processes for service requests

Under no circumstances should the software development team be delayed by service requests of any kind. The request process should be as simple and as fast as possible. The two most common service requests that can impact a developer are: Database management Database managers should be an integral part of the software development team and be included in all meetings where decisions are made that could affect the database. They are responsible for the integrity of the data. They're in charge of the layout and performance of the database, so they should challenge any change request that could cause delays in their delivery. If both parties (developers and database managers) agree on the database modifications, and it isn't a high volume of database change requests, it shouldn't take more than a few minutes to address. Security management Unless there are tangible reasons for strict security policies, software developers should not have to deal with expired or blocked passwords. Keeping up with more than five passwords to different systems, all set to expire monthly, and getting locked out during the most critical time on a project is frustrating. It takes developers away from important tasks to spend time on a call with the help desk to reset passwords.

Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 5 of 11

developerWorks

ibm.com/developerWorks

Minimize reporting of software metrics

Any organization has its own metrics to measure the quality and performance of the work produced by developers. Unfortunately, reporting metrics repeatedly is time-consuming, arduous work that drains a developer's valuable time. Metrics might not necessarily reflect the most accurate status of the project, either. A developer's time should not be consumed by producing metrics that require extra work and detract from the main job of writing software. In this situation: Minimize or eliminate reports I was once in an organization that required our team to fill out five different extensive reports weekly, get them signed by the project manager, and fax them to a different department that often requested more details and immediate clarifications. In the meantime, we were busy trying to solve an important technical challenge. Fortunately, the project manager stepped in and revisited the process. The resulting improvement was a weekly, low-key 15-minute meeting where each team member provided the necessary information. Reports should be kept to a minimum. Tune bug-management processes The purpose of a bug-management process is for quick resolution, not to produce reports. Many bug-management systems follow an extensive process life cycle that can produce more work than the fix for the bug itself. Back in the day, there was a ticket for a bug that was a simple misspelling in a label on a GUI. The bug had to wait a couple days until it was assigned to a developer, and then it was set to a status of "authorized to fix." Producing a fix took no more than 10 seconds. The bug-management process, however, required filling out a form providing details and specific descriptions of any code changes made, a screen shot showing the fix working, and creating a zip archive containing the fix. The same steps had to be repeated for every single bug reported during that project. The more streamlined the bug-management process, the sooner all bugs will be resolved. Cancel unnecessary meetings Meetings are an essential part of business life, but they can be time-consuming and sometimes unproductive. A coworker once tracked his time, and realized he was spending 20 percent of it in meetings that were largely unrelated to his actual job tasks. Project managers should carefully assess if an individual software developer or the whole team really needs to attend a scheduled meeting (or if the meeting is

Seven practices for healthier, faster software development Page 6 of 11

Copyright IBM Corporation 1994, 2007. All rights reserved.

ibm.com/developerWorks

developerWorks

even necessary). For some of us, it's very difficult to concentrate on one programming task, suddenly switch attention to focus on a one-hour meeting, and then go back to the task. In a meeting, my concentration is often still on the code on the monitor back in my office.

Improve communication with the business team

Getting the right information on time can drastically improve software deliveries. Business analysts, and anybody with the power to make business decisions for the software under development, should be available at all times for consultation and assistance. People must be flexible with their meeting schedules and activities to be able to work with the developers as required. The business team might have days packed with meetings while developers are awaiting a business decision or clarification before they can proceed with their work. In this situation, a full day of work is at risk of being lost. Software developers must be able to get the information they need as soon as possible.

Use the right programming language

This is not meant to imply that Java is better than C# or that C# is better than C++ or that Perl is better than Python. What is the right language? The one that your developers are more proficient with. A good developer is the one who masters one single language, not the one who knows just a little of several languages. To efficiently target any unexpected technical challenges that might pop up (and we all know they will), you need developers who have mastered the language being used. It is a big risk to assign a developer to a project just because its language is one of several that the developer knows or has worked with in the past. It's also risky to assign a developer to a project with the assumption that the developer will quickly assimilate a new language because the syntax or APIs are similar to one mastered. Not using the right language can cause your developers to do very ugly things that affect the quality of the code, just to get the job done.

Use the right integrated development environment (IDE)

You can't expect a developer with experience with one IDE to have the same level of productivity with another IDE just because both are of the same language. IDEs aren't perfect; they have different features that could contain bugs with workarounds,

Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 7 of 11

developerWorks

ibm.com/developerWorks

tweaks, and tricks that are known only to developers with a lot of experience on that IDE. First, identify the right tool for the job and then use it consistently. You should adopt a new IDE only if the project's requirements really demand it. The following are some tips for identifying the right tool. The right IDE must at least support: Incremental compiling Allows code to be automatically compiled upon saving, avoiding the need to recompile the whole project before execution. Recompiling is a very time-consuming task, especially when the project grows over time. Hot code replace Allows you to modify code, and immediately compile and execute while in the middle of a debugging session. Search utilities for classes, variables, and text Lets you easily find code elements without having to browse all the project files. Code navigation utilities Help you quickly access code elements without doing a manual search. Automatic code error warnings Improve your performance by immediately reporting any programming mistakes, thereby preventing finding errors later during compiling time. Code assist Provides pop-up help to complete code statements. Code formatting Helps to quickly format code so you don't have to do it manually while writing. Snippet and full source code view Let you visualize either a portion of code (method or variables) or its full source. Debugger

Seven practices for healthier, faster software development Page 8 of 11

Copyright IBM Corporation 1994, 2007. All rights reserved.

ibm.com/developerWorks

developerWorks

Allows testing and analyzing of source code by stopping its execution and proceeding to execute one instruction at a time. Finally, do your developers a huge favor and do not use tools in beta version unless it is absolutely necessary.

Conclusion
In this article, you learned about seven practices that can reduce overtime, cut costs, and speed up production on your software development project. Create a solid foundation for healthier development, and increase your chances of meeting deadlines with less stress.

Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 9 of 11

developerWorks

ibm.com/developerWorks

Resources
Learn Read the works of Paul Grahamessayist, programmer, and programming language designer. Get a gentle introduction to Extreme Programming. Joel Spolsky is a software developer who writes about software development, management, business, and the Internet. Dreaming in Code by Scott Rosenberg explores how our civilization runs on software, yet the art of creating it continues to be a dark mystery, even to the experts, and the greater our ambitions, the more spectacularly we seem to fail. In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena. Browse the technology bookstore for books on these and other technical topics. Discuss Check out developerWorks blogs and get involved in the developerWorks community.

About the author

Ezequiel Cuellar Ezequiel Cuellar, a senior systems programmer at Advanced Technology Systems, has nine years of industry experience in enterprise system solutions design and implementation. He has contributed to the creation of several large-scale projects for Fortune 500 clients.

Trademarks
IBM, the IBM logo, ibm.com, DB2, developerWorks, Lotus, Rational, Tivoli, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at
Seven practices for healthier, faster software development Page 10 of 11

Copyright IBM Corporation 1994, 2007. All rights reserved.

ibm.com/developerWorks

developerWorks

http://www.ibm.com/legal/copytrade.shtml. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Seven practices for healthier, faster software development Copyright IBM Corporation 1994, 2007. All rights reserved.

Page 11 of 11