Repository

In this repository, you can learn about clean code, that is essential for your code maintainability
https://github.com/ryanmcdermott/clean-code-javascript

Introduction

This post is an introduction of agile practices in software development, starting with some of my previous experiences with development, and what are the principles that will help you become agile, increase your deliveries and results. I start explaining the manifesto for agile principles, as individual and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. The link above is a repository that explains really well about Clean Code, that is a key part in helping your code easy to maintain, understand and evolve.

When I was in college, the professor used to give assignments with the description of the problem, the input of test cases and the output expected from the code. We should just follow some requirements on how to implement, and that was all. Sometimes, the professor just checked if the output of the code was right or the type of algorithm was right. After a while, since I had implemented, it was very difficult to understand and even remember what I had done.

On team projects, it was really hard to actually have more than 2 people working on the same code. When we updated some code we had to save the file somewhere and enumerate them, to identify which one was the latest. To understand what the other person had done was not easy.

College projects normally are not as big as software on the market, but if small projects are hard to manage by the way you do, imagine bigger ones.

It is essential to know what is agile, it could definitely enhance your productivity and make your deliveries more assertive.

Nowadays, I work professionally in building software. After learning about agile development and putting into practice, coding became easier, and working in a team became organized, doable, and manageable. Right now, I could say that we can deliver results that are valuable to the customer.

Software Development was mostly to be something like this image below:

It is really easy for a software project to become a nightmare. Sometimes the customer explains what he wants, but it is not necessarily what he needs. When the requirements of the project are a blur, things could go wrong terribly. Time is running, the costs of the project are growing, and you are rushing to finish the project, normally the quality decreases significantly. An outcome is a software that doesn’t satisfy the client, and the code hard to fix or change. To the point that it is easier to create the project from scratch again. What a loss!!

To avoid this waste of money, effort and time, a group of industry experts, the Agile Alliance,
created the values and principles that would allow software teams to develop quickly and respond to change in early 2001. Resulting in the Manifesto for Agile Software Development.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools

People
The most important ingredient of success is TEAMWORK. If people don’t work together as a team it is going to be hard to achieve the goal.

“A good process will not save a project from failure if the team doesn't have strong players, but a bad process can make even the strongest of players ineffective. “ according to Robert Martin.

A strong player doesn’t have to be a programmer with the best coding skills. An average coder that can work well with others can bring better results than a really talented one. A team with average programmers that can communicate well has more chances to succeed than a team full of “heroes” that fail to interact by themselves.

It is hard to have a team full of “heroes” who wants to “save the date” because all the knowledge is with each integrant.

According to Scrum, 3 to 9 people is ideal, less than 3 members, it may not have people with all the knowledge needed to do the work, more than 9 it could be hard to manage.

Teamwork is not easy, there are many team building tools, that can help the team become more united and transparent.

Process
The processes are important to potentialize your resources, changes may be necessary to make the process easier and more efficient.

How you are going to achieve the goal, is important, depending on the process, it could be easier or harder. I experienced two types of processes, the first one, the client explained what he wanted and we tried to deliver that, the schedule was not clear, the second one was with Scrum framework, that was really helpful, and made things easier to stick to the schedule and avoid impediments.

There are frameworks that can help improve the process like scrum, organic organizations, etc.

Tools
Tools are quite important to help you. “Good shoes can take you to good places”.
The good ones don’t need to be the best ones. You need to find what is beneficial to the project, within the budget. There are many tools that are open source that could help, so before paying a fortune to buy some tool, check if the ones that you already have can suit the purpose, and be sure there are no free ones that do what you need. (ex: compilers, IDEs, source code control systems, etc.)

There are really helpful IDEs that can help you hardly, like Eclipse, IntelliJ, etc.

Working Software over Comprehensive Documentation

Software without documentation is a disaster. It is easy to find libraries with lack of documentation that makes it hard to use and it demands a lot of effort and time to make it work. it is necessary to produce human-readable documents that describe the system and the rationale for design decisions.

According to Martin: “It is always a good idea for the team to write and maintain a short rationale and structure document. But that document needs to be short and salient. By short, I mean one or two dozen pages at most. By salient, I mean that it should discuss the overall design rationale and only the highest-level structures in the system.”

Too much documentation is terrible too, the code evolves fast, imagine that if every new change on the code you had to find and update all the documents that contain any subject related to the code you changed. It would be hard to maintain the documentation updated.

Documentation is important it can help a new programmer to understand, but the best way to transfer the knowledge about the project is by the team and the code itself. Individuals and interactions over process and tools, it is going to be easier for a new programmer to learn about the project by pair programming or asking directly to a teammate.

The code itself is the document that has all the updates (please, code versioning is essential), and it does not lie about what it does. As one of the most important documents for transferring information, it should be clean and organized. It may be hard to extract the business value or the intent from the code. But the team has the roadmap of the system in its members’ heads. The fastest and most efficient way to put that roadmap down on paper and transfer it to others is through human-to-human interaction.

It is important to keep your code easy for any programmer to read, understand and maintain. You could learn about Clean Code and put it into practice, you will notice the difference right away. To learn about Clean Code I would recommend this tutorial of Ryan McDermott in GitHub:
https://github.com/ryanmcdermott/clean-code-javascript

Customer Collaboration over Contract Negotiation

You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price. Many attempts to treat software projects in this way have failed. Sometimes what the customer wants is not what he needs, if you follow work as cooking a recipe it may not turn into something that satisfies the customer.

When you take into account and analyze what are the problems that the customer has, and what is he trying to improve or solve by technology. Together we can find out what is the best way to solve the problems, with constant feedback about the things that have the potential of helping your client and the things that are not.

A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed. In most cases, the terms it specifies become meaningless long before the project is complete, sometimes even long before the contract is signed! The best contracts are those that govern the way the development team and the customer will work together.

Responding to Change over Following a Plan

The course of a software project cannot be planned very far into the future. First, the business environment is likely to change, causing the requirements to shift. Second, once they see the system start to function, customers are likely to alter the requirements. Finally, even if we know what the requirements are and are sure that they won't change, we are not very good at estimating how long it will take to develop them.

A good planning strategy is to make detailed plans for the next week, rough plans for the next 3 months, and extremely crude plans beyond that. We should know the individual tasks we will be working on for the next week. We should roughly know the requirements we will be working on for the next 3 months. And we should have only a vague idea what the system will do after a year. This decreasing resolution of the plan means that we are investing in a detailed plan only for those tasks that are immediate. Once the detailed plan is made, it is difficult to change, since the team will have a lot of momentum and commitment. But since that plan governs only a week's worth of time.

What I experienced with discussing things in detail about things that are not going to be done in the same week is that many details are forgotten as time passes. And when we finally get to work on the feature, we were not sure about what was discussed and sometimes, things that made sense some time ago, do not anymore.

Through iterative management, like method PDCA (Plan. Do, Check and Act), used in business for the control and continuous improvement of processes and products, we can solve the problem of the customer through multiple iterations of it.
The image below illustrates well, multiple iterations of the PDCA cycle can be done until a problem is solved.

In the first step, we establish objectives and processes required to deliver the desired results.
This plan should be flexible and ready to adapt to changes in the business and technology.
The second step is to Act, the do phase allows the plan from the previous step to be enacted. Small changes are usually tested, and data is gathered to see how effective the change is. The ability to respond to change often determines the success or failure of a software project.
The third step is Check, during this phase, the data and results gathered from the do phase are evaluated. Data is compared to the expected outcomes to see any similarities and differences. This helps to see what changes work better than others and if said changes can be improved as well.
The last step Act, also called Adjust, is where a process is improved. Records from the “do” and “check” help identify issues with the process. It can be problems, opportunities for improvement, inefficiencies and other issues that block us from optimal results.
We should find out what are the root causes of the problem, and eliminate them by modifying the process.
Planning for the next cycle can proceed with a better base-line. Work in the next do phase should not create recurrence of the identified issues; if it does, then the action was not effective.

Resources

For more information you can access the Manifesto by the link:
https://agilemanifesto.org

This post is based on the book Agile principles, patterns and practices in C#, written by Robert C. Martin (“Uncle Bob”) and Micah Martin.