The new generation works in a different way. Especially when it comes to software development. It makes sense. During Education they are fully dependent on themselves most of the time. Teachers can’t keep up with the pace of new innovations. We can’t blame them for that, nobody can. It’s just going too fast and the amount of information has become too much for one person to absorb.

What’s happening now is that these youngsters find their own way to handle projects. They have enough basic knowledge and a great problem solving talent. When they start a project they look for information they need for that particular project. No problem because it’s available 24×7 on the internet. They describe the solution, get approval for it and just start working. They make mistakes along the way which will be solved during development. This fact inspired me to create a new development method. Slightly based on the methodology which is used for developing social games. A method that I will use for Gamification projects!

First of all, drop the huge paperwork. Focus on the fundamentals of the software first, the basis on which everything has to be build. Don’t lose time on describing every tiny detail that nobody reads or understands anyway. Keep it simple. Discuss it with people that have sufficient knowledge to gain useful comments and start building a prototype (or mockup) as soon as possible.

Traditional ways of developing software are based on making money, not necessary on creating a good product. Yes, that is a bold statement! This is something you can recognize easily in bigger projects. Big projects is like hitting the jackpot for traditional ICT companies. This is why:

1. Do whatever the client wants. It means more work = more money.
2. Document everything very thoroughly, before starting a project. Everybody knows you need specialists for that and they don’t come cheap. Documenting everything is a lot of work = a lot of money.
3. The bigger the documentation pile, the more developers and project managers you need. If it gets really technical the client can’t follow what’s going on, so fill in the possibilities this opens yourself. It’s similar to the ones I mentioned before.

Putting money aside, there is also a big chance these projects will fail:

1. People are never really involved. It’s a job, they get paid for it. Often there is no internal drive that creates real motivation.
2. Preparation of a big project can take up to a year. In one year the world around us can be completely different when it comes to technology. Before development starts the project documentation is already outdated.
3. Huge project turn an interesting job into a boring one. There is a reason why people don’t like ICT that much. Programming isn’t boring, the way we handle projects is. Making something that is defined by someone else in detail isn’t ideal.

Can this be solved? I firmly believe it can. We need a different approach, in which the following applies:

1. Trust! Make developers really responsible and trust them.
2. Guide and help people, don’t manage them!
3. Limit documentation. Only write down the necessary information.
4. Allow everyone to make mistakes! They are learning points and the fastest way to improve your product. Mistakes can be a spark for great innovations.
5. Start from a basic idea, be flexible towards your goal. It’s the journey that leads to a solid solution! It’s called evolutionary development (Plus 4).
6. Release the first version a.s.a.p. It doesn’t have to be perfect at all. The base has to be correct, it’s the foundation.
7. Use information and knowledge from stakeholders.
8. Collaborate!
9. Enjoy the ride!

At the end I was struggling creating this method. I even thought I was done. Couldn’t put my finger on it, but something wasn’t right. That’s how my mind works, when something is wrong I can feel it. Might sound strange, but in this field of expertise I use that as my guide. The four steps: 1-Involve, 2-Create, 3-Release and 4-Evolve where perfect. So that wasn’t it!

After discussing this with Vincent Ariëns (thanks again) from Seats2meet it stroke me. It doesn’t stop at step four. At step four we learn and create a new requirements list to improve the software. We keep repeating all steps faster and faster (we are evolving, which means we understand everything better every time we hit base), until we are satisfied, or could even be infinite. At step one we check if the requirements matches the basic idea. This is a great way to keep in pace with all the developments that surrounds us.

When the software becomes completely obsolete we just start all over again.

Plus 4 will make it hard for developers to fail!

Any questions, remarks are more than welcome like always. I am almost done developing this method, please be patient.