Resumo

Traditional software development was based on the idea that requirements for software projects are fixed and possible to write down in advance. That almost never worked. Projects collapsed, schedules were broken and programmers were frustrated. Changes in requirements in the middle of the fixed sized projects tend to do that. Why change requirements? Because the market changes, or new ideas come up, or some part of the planned system is not needed anymore. The client expects to be able to add or change project features inside the same budget. Developers don't expect that.

So after a while, some smart developers invented a project management technique which is actually expecting requirements to change. They called it Agile Development. It is based on fixed sized deliveries in short "sprints" - development cycles that are two or four weeks long. This way, client can see the software features while it is under development. It is possible to give up from a requirement which is not yet developed. It is possible to change the requirement. It is possible to stop the project at the end of each sprint; or extend the project by adding new features and sprints. Nothing is fixed, you just subscribe to sprints and stop the subscription when you decide that the software is complete. That's how we would like to work. Agile development reduces the risk for both the client and the developers.

We are aware that sometimes you have a fixed budget and there is no room for flexible sprints in development. In that case we have to be clear that we understand the requirements so we can estimate the cost of the development in advance.

Regarding the development work, we are something like a 50/50 mix of theoretical and practical. So yes, we can be annoying and insist on design patterns or test driven development, but we still get the job done.