Posts Tagged ‘ agile ’

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.

2010
04/01
CATEGORY
books
TAGS

Tinggalkan komentar

Resume of the Practices of an Agile developer – part 3

Moving on to chapter four, there is no perfect project; there is no software on this world that could resist the effect of changes. It is inevitable that the software requirement will change, because the nature of improvement, the requirement of the software will likely to change. One thing to remember is, developer should realize that not all the decisions on development should be taken by the software developer. It is important to involve the customers on every decision that could affect their business. It is dangerous to decide for yourself; therefore you should be able to decide what you shouldn’t decide. Every time you face the customer to present a demo of your software, present the details of your software in a language they can understand.

Just as important a design is for development process, do not let design dictate you. Design should only be as detailed as needed to implement. Design should be similar to map, it is point you to the right direction, show you the goal and constraint, but not the detail of the journey itself. By using this design as a map, we will be able to evolve the design, not dictated by the design.

Don’t go blindly picking up a framework just because it is nice to put up on your resume, there are several questions that you had to ask yourself before you use a technology : Does it really solve the problem ?, Will you be tied to the technology ?, and how about the maintenance cost ?. all of this questions are essential to your decisions to use a certain framework, tools or a language.

Always keep your code simple and maintainable, don’t build what you can download. Because the less code you write, the less you have to maintain. Choose the technology that you needed, determine your needs first, and then evaluate the technologies for this certain problem. Also, you have to keep your code executable, by doing this; we will always have a code that stable and executable every time we wanted to run it. There are few tips to keep your code executable, first run on your local machine, second check the latest source version to avoid incompatibility. Lastly after you test everything, and sure that there are no conflict you could check in your latest software.

Integration of software is usually put in the least important section of our agenda, but this book encourages us to integrate early and integrate often. By integrating early you get to see how subsystem interact and operate. The earlier we understand and address the issues found on the early integration, the less work we have to do on fixing them.

It is also important to keep your deployment automated at the early stages of the projects lifetime. It is to ensure that the person who uses our release able to understands and gave feedback as an improvement to our design and code. Frequent feedback are essentials to agile development, because the nature of the requirement which is as fluid as an ink. Requirements are never frozen. Nobody’s mind or perspectives are frozen in time, especially your customers.

In the ideal world of software development, we must be able to deliver a product that the customers came to wanted, not the products that the customers came to asked for. The feedback provided by the customers in the software demos are essentials to the improvement of the software currently developed.

One test is worth a thousand expert is the first sentence that greets us in the opening of the next chapter, chapter five. This chapter describe to us about the agile feedback. All of the feedback we got from the user, QA and other people are turned into a code eventually, and code must eventually be tested. The testing methods provided in this chapter included the unit testing and the benefits of unit testing. Unit testing provides an instant feedback, unit testing make your code robust, and so on. A good unit test can warn you about problems earlier.

There are techniques known as Test Driven Development, where we only code, after writing a failing unit test for that code. The test comes before the code. By using TDD, we are viewing our code from a different perspective, we see the code from the user perspective, not he implementer or developer. The better the design is, doesn’t mean that there will be more classes. TDD can be used as design tools to help us make a better code.

When there are things that are different, chances are it will make a difference. To avoid this case, we must thoroughly test and run a unit test on each supported platform and environment combination. Find the problems, before they find you.  After all the effort you took to make an output out of the program, you must make sure, that the output you are getting at is correct, therefore we must check the result with the actual data from the user / customers. Create a test case for core business logic. Have your customers test this in isolation, and exercise them automatically as part of the test run.

The importance of time keeping is also the main point in this chapter; we must always measure the real progress of our work. Focus on where you are going!, make a timesheet to keep record of your progress. Even without the timesheet, some developers have difficulties to focus on reality. You have to measure how much of your time is left. Every complaint that you hear, holds a truth, find the truth and fix the real problem!

There are two ways to create a software design; one way is to make it so simple there are obviously no deficiencies. And the other way is to make it so complicated, there are no obvious deficiencies. The code that you wrote must clearly communicate your intent and must be expressive. By doing so, our code will be readable and understandable. Once our code is not confusing, it will also avoid some errors. Write the code to be clear, not to be clever.

To communicate your code, there are two ways; the first way is to use the code itself. And the second one is to use comment to explain non technical issues. Source code should be understandable for its clarity and elegance, not for its comments. Do not comment your source code to cover up the mess.

The big deal in most documentation is naming, if you could name your code to actually mean something, or explains what it’s doing, then, it is a good name. If the name conveys nothing, then it’s a bad name. The worse thing is when the name made you lost. With a well chosen name and a clear execution path, the code needs very few comments, But the most important thing is, do not use comment to substitute a good code.

Code in incremental fashion, are also important for developer. Don’t code for hour, even minutes, without stopping to check where you are going. When you code incrementally, little by little you will make a smaller methods and a more cohesive classes. A simple code, simplicity is good. Simplicity does not mean simplistic, amateurish and foolish. But it is more difficult to achieve than a mere complex code. One way to measure the quality of the design is to listen to your intuition. A good design will make you feel comfortable.

Upon writing a code, we will have to count the cohesion factor. Cohesion is the measures of how functionally related the members of components are. A higher cohesion value means that the members work toward one feature or set of features. Lower value cohesion indicates that the members provide a disparate set of features.

2010
04/01
CATEGORY
books
TAGS

Tinggalkan komentar

Resume of the Practices of an Agile developer – part 2

Chapter two of this books also emphasizes the importance of being positive for every idea, because negativity towards idea stated are killing the innovations. We have to respect others idea, because the dangers of clash between the ideas on the teams are dangerous. Productivity and innovation quickly dies on those teams. Feel free to express and state your idea, because it may help to create a solution. Criticize the idea, not the people.

Sometimes, even the best plan in the world will go to waste, if there is not enough courage to execute the plan. There is certain situation that needed courage, rather than carefully crafted plan, it is important to state the right thing to do, rather than stand still and do the wrong things. Do what is right to do.

With chapter two wrapped up, now is the time to move to chapter three. Chapter three discusses about the importance of keep moving. Keep learning new things, and unlearning the things that is not needed anymore. It is up to ourselves to keep us informed of new technology and makes ourselves up to date, because the only one that cares about us is ourselves. There is nothing permanent except change. And in order to keep up with the change, we must continue to learn, a constant, small exposure is good, rather than a rare and long study session. The hardest part of learning a new thing is to let go all the habits we obtain in previous language or methods. We don’t have to be an expert in everything, but we should at least stay aware of the latest trend, and prepare for it.

There is another important thing about keeping yourself up to date, instead of making yourself the only member on the team which is smart, and updated enough, you should raise the bar for your team and for yourself. You will have a strong and capable team, which is able to overcome a difficult project much more easily. Don’t keep the knowledge to yourself!

Instead of keeping all the knowledge and habits from the past, we must know when the time to unlearn. It is dangerous to keep all the habits from the past into your relatively new software, because it will affect your design and coding techniques. Old habits are hard to break and even harder to notice, it is hard to let go, because the time and effort to refine the techniques are not small. It makes people thinks twice to let it go. When you learn a new technology, you must let go the old habit that hold you back!

We must realize that sometimes, we thought that asking a question would not solve the problem, wrong! In this book, we are encouraged to ask “Why??” Don’t just accept what you’re told. Keep questioning, until we finally understand the root of the problem.

Facing the uncertainty of the schedule and habit can affect our rhythm, mentioned in this part is how to keep our rhythm steady and ready for anything that comes next. It is always easier to act, when we already getting used to the rhythm. Always prepare for the things to come. Regular rhythms will make it harder to hide things, and gives you an excuse to have courage.

2010
04/01
CATEGORY
books
TAGS


Tinggalkan komentar

Resume of the Practices of an Agile developer

Practices of an agile developer is a good book for all developers, be it a beginner developer, or an expert developer. This book’s cover the aspect which is very important all the developer aiming to be a better team player (team member). Consisted of nine chapters, this book explains the very foundation of Agile is. The very first chapter of this book explains that the world of developing software is not as simple and linear as a deterministic road (proverbial road). But it is described more like surfing, which we will encounter a very dynamic and unpredictable seas, and maybe even sharks!

Agile, mentioned in this book, refers to ability to be able to react quickly, and adapt to the situations. As mentioned before, the world of developing software is very similar to the sea, where the waves are constantly changing and unpredictable. The ability to adapt to situation, both on surfing (as described as example), and developing software, are very crucial to reach our goal.

The most interesting things mentioned in chapter one, is the agile manifesto. Agile manifesto is a manifestation of ideas of seventeen people, discussing about emerging trend, something called Lightweight Process. Agile manifesto stated that:

  1. Individual and interactions valued more over processes and tools
  2. Working software valued more over comprehensive documentations.
  3. Customer collaboration valued more over contract negotiations.
  4. Responding to change valued more over following a plan.

All the point stated in agile manifesto, valued more interactions and the ability to deliver a final product (which is working software) over the things mentioned on the right hand side. The importance of continuous feedback in agile development are huge, because agile developments, relies on constant feedback to make constant adjustment in a highly collaborative environment.

continued later…..

2010
03/30
CATEGORY
books
TAGS


Tinggalkan komentar