This post was written for the Plutora blog. You can read the original here. In 2001, the Agile Manifesto surfaced. It wanted to change the software development process. The manifesto has four central themes, but not many people know that there are also 12 Agile Principles. These offer more concrete examples of how agile software development should take place. Many years later, almost every organization will say they “do agile” but many only provide lip service to the values and principles of the
I’m not a database guy. In fact, it’s one of the aspects of programming I least like. So it surprised some of my colleagues when I told them I was attending a session at Techorama aimed at DBAs. But the description struck a chord with me. Grant Fritchey gave a session named "Solving the Database Deployment Problem". In my short career, I’ve only seen one place where database deployment was done correctly. And it was my first employer. Every change
After having applied TDD for several years now, and after having assumed my colleagues do the same, I have been surprised lately to hear how many developers write their tests after their code. Test-driven development is meant to be: Write a test See that it fails (and fails correctly) Write your code See that your test passes Refactor (and see that your test and all others still pass) This has led to the well-known (for some) red-green-refactor adage. If you
Thinking about it, the team I work in has quite a lot of ‘security checkpoints’ for our code. We try to put as many pieces of code under unit test. However, we are often hindered by an old framework that can be described as a sort of ‘CSLA meets Active Record’. If unittests are impossible, we will make fit-tests (using FitSharp). We develop using the Scrum methodology, and, after you finished your task, you can stick the post-it in the
Ok, not everyone does, but you have to admit it’s a trend in the software development world and a good one for that. But if you’re already developing in an agile manner or plan to, take 5 minutes to stop reading about scrum, TDD, XP and other Agile methods and check out the basics. In other words, read the Agile Manifesto, and see why we’re doing agile software development. Also, be sure to read the twelve principles behind the manifesto.