Resume of the Practices of an Agile developer – ends
Chapter seven of this book consisted of agile debugging. Even on the most talented agile projects, things such as errors, bug and defects still happens, this chapter explains to us, how to deal with debugging process by agile methods. The first thing mentioned about agile debugging is that we as developer had to maintain a day log. A log that keep records about the problem and solution that we have already faced, so we don’t get burned twice. Our log has to be in a computer searchable format, to ease the searching process. Even better, we should share our log, and make it wiki format, so the other developer could see the content of the log, and update it as necessary.
Treating warnings as error is essentials to agile debugging. Treating warnings lightly is like having a bomb ticking under your seat. It could blow off anytime. Treat compilers warning as error! Checking in code with warning is like checking in code with errors or code that has failed a test. A checked in code, should produce no warning and errors from the build tools. Just because our compiler treats warning lightly, doesn’t mean that you should too.
When you face an error, the best thing to do is not going through line by line of your code, because it is a waste of time. Attack the problem in your code in isolation, therefore saving your time. The positive side of having unit testing is that we are forced to layer our code. Without it, we will find it hard to find the problem and start to solve it. Do not try to solve the problem by going through the whole system, because it is very hard to separate the details of the problems that affecting your code and the one that doesn’t. Attack the problems in isolation; separate the problem from its surrounding when working on it. But, before you isolate and debug, remember to always check your day log for any solution on the problem.
Reporting all the exceptions is important for any software, handle or propagate any exception you find, do not suppress them even temporarily. We always have to assume that our code will eventually fail sometimes. Related to that is also the importance to provide a useful error messages. An error messages is only useful when it is explain to the user, what is really going on, what went wrong. A simple one liner error messages such as “error”, “try again” and “cannot login” is useless. Maybe it is clear enough for the developer, but it is certainly won’t enough for the customers. Present a useful error messages, provides an easy way to find the detail about the error. Basically, there are three types of error. The first one is, program defect. Second one is environmental problems, such as failure to connect to the database. And the last one is user error, such as typo, etc.
The next chapter of this book, chapter eight is about agile collaboration. The first step in agile collaboration is to schedule a regular face-to-face meeting between the members of the team. With a regular schedule of face to face meeting, there would be no problem that is hidden from the team. In the meeting each of the team members has an equal amount of time to speak their concern, problems or thought about the project. Hopefully the other members are capable to help that particular problem.
The architect role in the team is very important; an architect is the person who designs software and have the design turned to code by programmer. It is wrong to assume that designer only design software. They are also has to code a bit. The designer’s job is to mentor the development team, and to raise their level so that they can take on a more complex matter. A good design evolves from active programmers. Real insight comes from active coding. Do not use an architect who didn’t code, they cannot design without knowing the reality of the system.
Always remember to emphasize the collective ownership of the code. When only one developer handles a piece of code, there is always a risk that the code will be understandable only by that person. to avoid that, and to increase the team understanding of the code, it is always preferable to rotate the developers across different modules and tasks in different areas of the system. To raise the performance and the competence level of a team, there have to be some knowledge sharing involved. By sharing your knowledge, you will make other member of the team more competent, and give motivations to keep improving. Be a mentor.
But, being a mentor means that we have to teach our members of the team how to solve a problem, not solve the problem for them. By doing this we will have a lot of benefits such as teaches the person how to approach a problem. Give others a chance to solve the problem. Point them in the right direction and instead of handing them the solution. That way, everyone can learn in the process.
There is a habit of checking in code often. It is a good habit, if the code were truly working. How if the code that checked in didn’t work? It will be a hindrance to other, and slow their work down. Share code only when ready. Never check in code that’s not ready to use. It is even considered an act of criminal project negligence if the code that doesn’t compile or pass its unit testing. Therefore, it is important to review all code. Code reviews are invaluable in improving the quality of the code and keeping the error rate low. Don’t forget to always publish your status. It is important to notify other members of the team where are your progress at, is there any idea that they could use? Don’t wait for others to ask you the status of your work.
Finally the books come to a close. In the epilogue there are several tips and trick about applying the agile methodology on real life. The books are a great and exciting to read.
Everlasting Memory of LIFE 