KISS and YAGNI

Two basic philosophical aspects that will lead you to success are "KISS" and "YAGNI". No matter what you do, always follow them, I'd say that they are the basic priciples behind agile development. And if I look back, each time I had problems with a project during the last few years, these problems were finally caused by non-respect of KISS and YAGNI.

But don't underestimate the power of the dark side: ignoring KISS and YAGNI is the easier way, and following their philosophy is often hard and conflicts with our developer or manager "instincts".

KISS: Keep It Simple, Stupid

First of all, keep everything as simple as possible. The feature set, the human interface, the code. Everything must be as simple as possible and easy to understand.

YAGNI: You Ain't Gonna Need It

Only do what's really needed to reach your target. Only implemented the features end users will really need to work properby, but make yure that the features you do implement are really working fine.

The basic agile principles

As said before I'm describing my own perception of agile development here. The following principles are based on Extreme Programming (XP) as well as on other agile frameworks, and I also reorganized everything a bit so that's as much consistent as possible.

1 - Respect

For me, agile development is all about RESPECT. Respecting the customer, respecting the development team, respecting the developer as a human being. It's about emotions, moods and feelings, and taking care of the developers welfare will automatically have positive effects on the software quality and success.

2 - The planning game

Planning an agile project is completely different from traditional planning methods. We call this the "planning game", which is some kind of "brain storming" where feature ideas are written onto small cards. If you're planning an inhouse project, make sure everyone in your company or department takes part in these sessions, if you're developing something for a customer make sure all key members of the customer department that shall later use the software are present.

Now that all possible features have been written down, you will have to re-organize them. You may regroup them (easy to implemented, harder to implement, very hard to implement for example) or simple order them (starting by the most easy to implement feature, going up to the hardest one).

Finally you'll have to select a number of cards that shall represent the first release of your project. I strongly suggest to only start with those features that are a) very easy to implement and b) absolutely required to start running the software. Your primary goal should be to launch the first release within a few weeks (2 - 6 weeks for example), no matter what your resources are. Reduce the feature set to an absolute minimum, focus on the code quality and the usability.

3 - Shared understanding

A very important point is that everyone understands everything during the entire process. By "everyone" I mean the management, developers, the customer, the end user, and by "everything" I mean the idea behind the project, the marketing concept, the sales plan, development techniques, eventual problems and risks, etc.

It's very important that everyone involved in the project understands everything related to it, as this is the only way to guarantee that every single member in your team knows exactly what to do to stay focused on where you're heading to. Therefore, keep your team small (not more than 15 people for example) and make sure that everyone knows entirely what your project is about and that everyone is absolutely convinced that the entire team is heading into the right direction.

3 - Continuous, small interations - release fast, release often

After you've released your first software version (only a few weeks after you're first meeting if you did well), install it and start using it. If you're creating a software for a specific customer, give your customer full access to this first prototype and make sure everyone is testing it as often as possible. In the meantime, fix bugs that have been detected, improve the interface, select the next cards and implement them (selecting the next cards may require a meeting with the entire team, including the end customers). If you're creating a web based software project, think about releasing an early public prototype that can be tested online so that you'll instantly get feedback.

The goal is to release stable software as often as possible. The number of released may depend on the complexity of your project and on the resources behind the project, but it's always possible to release on a regular basis, at least once a month! A new CorneliOS release becomes available at leat once or twice a week, so there is a new release every 3 to 4 days. Sometimes a new release only fixes two bugs and adds a minor feature, but that's absolutely okay.

Prevent changes that take weeks or months to complete, always try to break up complex problems into small and simple tasks that can be processed by a single developer within a few days.

4 - Fine scale feedback

Feedback is a very important factor when doing agile development. What we're looking for is fast, precise and "useful" feedback. The easiest way to get such feedback is by offering regular software updates tested by a large number of end users. Therefore we must release updated software as often as possible, and make it accessible to the end customers. Getting feedback is not easy at all, therefore a large user base is often an advantage.

It is also very useful to get feedback quite early in the development process. End users can tell you instantly what's wrong with the interface or the process logic for example, and changes can still be made quite easily in early development stages.

Feedback should focus on various aspects: bugs, interface/usability and feature/process implementation.

5 - Test driven development

In most cases developers write some code and later evaluate if the code really does what it should do. There are several problems with such an approch. First of all, if your software reaches a ceratin complexity, if will become quite impossible to test every imaginable situation. You will need a larger number of testers and a lot of time to ensure software quality this way.

Test driven development means doing the exact opposite. Before starting to code your program, you first write a "test suite", which can be a descriptive file for an existing test framework, or a standalone test program. Your test suite simulates a user or a program calling the fuction you wish to implement, using all imaginable input variations for your new code and comparing the output with predefined values in your test suite.

Test driven development offers much better results when implementing new features, in helps to eleminate bugs right a first development stages and ensures a high code quality even if changes are made later on (as the test suite is expanded with each change and is run before shipping a new release).

But there are also some critics. Test suites cannot perfectly simulate human behaviour , and you will always forget certain possible cases in your test suites. Test suites can be very helpful, but it would be a huge mistake to completely rely on them without doing any human testing in parallel. Another problem is that it's really hard to implement test suites for graphical user interfaces in most cases, so that test driven development is often limited to core feature testing.

My suggestion is to use a maximum of both test driven development and human testing to ensure the best possible softwae quality. Never rely on one of them alone, as both have their advantages but also their limits.

6 - Coding standards

Coding standards are very important when working in a team, and I strongly suggest to use them in every project. A good starting point is to look if there are official guidelines for the programming language you're using, and to use them as a basis for your own guidelines.

The goal should be to create software code that's easy to read and understand and that allows each developer in your team to fix and update each piece of code in your software. Avoid large code files, and always break up complex code into smaller and easier sniplets. Many programmers think it's cool to always use the latest tricks and hacks in their code, but today I prefer simple and straight forward solutions that will reduce the maintenance costs - remember, most end users will probably never see a single line of code you ever developed, so serve the interests of your team and keep it simple.

7 - Development team welfare

Still to come...

8 - Programmer welfare

I've mentioned it before - software development is an emotional process, and the quality of the code will largely depend on the motivation and awareness of the individual developer. A highly motivated and focused developer (or any other employee) working 6 hours a day will produce much better results than a frustrated and ignorant developer in 12 hours or more.

So here's my statement: don't ever work more than 8 hours a day and 40 hours a week (that's true for everyone in your company, but especially for developers). If you can't do everything you need to do within 8 working hours, change the way you're doing things and optimize your work, never add working hours. If you have too much to do, working more and more hours is always the easiest way to solve the problem, but it will make you tired, it will prevent you from finding new ideas and optimizing your processes.
I personally think working about 6 hours a day is best, plus about 1 hour where you're surfin' the web, looking for new ideas and ways to further improve your processes. In most cases this will mean working from 9:00 to 17:00 for example, which should then include a break (lunch from 12:00 to 12:30 for example, sometimes even sponsored by the company) and some time to surf, to read (web and books) and to learn new things.

But be careful: reducing the number of work hours will only become a successful experience for your company if you optimize the entire work process, and you'll need highly skilled employees that are really able to get beyond a certain point of self-optimization and you need a strong agile enterprise philosophy (by the way, these are probably true for the entire agile development and agile company stuff).

Thanks for reading my agile pages!

I hope you liked my agile pages, and I hope that they even might help you to develop better software and release it on time. I add new stuff to these pages and correct them on a regular basis, so check back from time to time to see what's new. Feedback is always welcome, and don't forget to bookmark my site!

Best regards
Jos Kirps


(c)1996-2010 Jos Kirps | All rights reserved | Privacy Policy | Site Map | Rate this site