It takes some time to realize the real life implications of the Agile approach on everyday tasks. Have you ever made your project very complex because you’ve forseen thousand ways to crash your application or to missuse it? Very often this kind of attitude leads to the point where you start overengineering. Why? Agile software development takes part not only in our work environment but also in real life. How it affects your everyday decisions? Agile is a mind altering change. There are few very common patterns in software development that may apply to the real life usecases.

YAGNI - You aren't Gonna Need It

I see overengineered solutions every day. A lot of folks try to add as many features as they can. “This will be useful…”, “There will be a day when this might be a good thing.” Do not lie to yourself. It is very unlikely, that there is going to be such a date on wich you may need this feature. Unless this day comes, do not waste time on it. Time is the most precious asset and you’re loosing it on things that you probably “aren’t gonna need”.

KISS - Keep It Simple Stupid

This one is my personal favourite. Leonardo da Vinci has a saying: “Simplicity is the ultimate sophistication”. This phrase has been adopted by Steve Jobs in his pursue of purity in design. You might not be a fan of his however you have to admit that he made it possible to use a computer by the non-technical people by keeping it simple. KISS is a process not a product. Simple isn’t the same as featureless. Simple is easy to use. Apple devices could be operated by small 3-4 year kids. This is something that you should think of. How they did it? This is one of the factors of their products successes.

DTSTTCPW - do the simplest thing that could possibly work

This is a crucial part of TDD. Write a test and then the simpliest code that asserts positive results. Why not use that on daily basis? Do not overengineer. Evolution not revolution. I will cover this in the future posts. Do not fear the refactoring. Write simple. Run. Refactor/change. Run again. Do small iterative improvements. Big changes fails.

Work with the client

Unless you’re coding for your own plesure the most important part of the development process is to sell your product. Applications should satisfy the client needs. Why not make it by small improvements every few days. Showing your product to the stakeholders to verify whether you’re doing it right. This is in my opinion even more important than a strong contract. Be agile and work with the client. In the end it is he or she who pays for your bills. A happy client will recomend you further. An unsatissfied one will spread a bad word of you. It is easier for others to believe in bad things than good ones. Do not give them the chance to do so!