One of the philosophies of the Agile model is the importance of building workable code in short sprints on an ongoing basis. There are a number of techniques that are ingrained in the Agile model that result in more straightforward and elegant code.
Code as simply as possible. Some programmers take pride in how sophisticated they can make the code. An Agile programmer instead takes pride in how simple the code can be to accomplish the expected result. This simplicity is the most effective over the long term.
Build for today. Your code base should focus on fulfilling the user stories and requirements that are part of your current iteration. Do not add code to solve future user stories or potential functionality. These future features will be concentrated on when they are chosen in some future iteration.
Code as flexibly as possible. At the same time that the code is simple, it also needs to be flexible. You want to be sure you don’t make decisions that are perfect for your first iterations, but then don’t allow you to easily add more and more features and functions in later iterations. Another Agile philosophy is to make decisions at the latest responsible time. This does not mean to procrastinate. It simply means to maintain options and flexibility as long as possible so that decisions can be made with as much information as possible.
Document the code. If you are trying to track down problems in code, you are not going to be able to find the problem in a programmer’s manual. The only place you are going to track it down is the code. Even if the client asks you to investigate how a feature works, you typically cannot rely on an external programmer’s manual. The only way to know for sure is to check how the code works.
Build for today. Your code base should focus on fulfilling the user stories and requirements that are part of your current iteration. Do not add code to solve future user stories or potential functionality. These future features will be concentrated on when they are chosen in some future iteration.
Code as flexibly as possible. At the same time that the code is simple, it also needs to be flexible. You want to be sure you don’t make decisions that are perfect for your first iterations, but then don’t allow you to easily add more and more features and functions in later iterations. Another Agile philosophy is to make decisions at the latest responsible time. This does not mean to procrastinate. It simply means to maintain options and flexibility as long as possible so that decisions can be made with as much information as possible.
Document the code. If you are trying to track down problems in code, you are not going to be able to find the problem in a programmer’s manual. The only place you are going to track it down is the code. Even if the client asks you to investigate how a feature works, you typically cannot rely on an external programmer’s manual. The only way to know for sure is to check how the code works.
Since the code is the ultimate description of the code, it is important the code be understandable. This requires the code itself have plenty of comments. These comments don’t reflect the obvious, but are there to point out creative techniques or describe major sections of code that enable certain features and functions. The code also needs to be simple to review and to understand by others who will follow you.
Share ownership of the code. In a traditional project, each programmer is responsible for certain programs and components. The programmer creates the code and unit tests it. Later, if there are bugs in the program, the initial programmer is responsible for fixing the errors. In an Agile project, the team takes collective ownership of the code. One programmer may create the code (or perhaps it was created by two people using pair programming), but anyone may be assigned later to update the code. The code may need to be updated because of new requirements in a later sprint or to fix a bug that was not uncovered earlier. Anyone – not just the original programmer – may be assigned.
Refactor the code. When a programmer is assigned to an existing component, he has the flexibility (and the obligation) to look for opportunities to simplify or refactor the prior code base. The code will hopefully be more efficient and simplified by having multiple programmers work on it at various times during the project.
Share ownership of the code. In a traditional project, each programmer is responsible for certain programs and components. The programmer creates the code and unit tests it. Later, if there are bugs in the program, the initial programmer is responsible for fixing the errors. In an Agile project, the team takes collective ownership of the code. One programmer may create the code (or perhaps it was created by two people using pair programming), but anyone may be assigned later to update the code. The code may need to be updated because of new requirements in a later sprint or to fix a bug that was not uncovered earlier. Anyone – not just the original programmer – may be assigned.
Refactor the code. When a programmer is assigned to an existing component, he has the flexibility (and the obligation) to look for opportunities to simplify or refactor the prior code base. The code will hopefully be more efficient and simplified by having multiple programmers work on it at various times during the project.
If you look at the total lifecycle of an application, only about small percentage of the cost and time is spent during the development project. The larger percentage is spent in the support and maintenance phase. If you build a good application, the code might run in production for ten years or more. Simple, straightforward and optimized code allows easier understanding, easier error fixes and easier enhancements over the entire lifecycle.
