This week is dedicated to software development methodologies. So to start with here is a simple overview.
If you see my Skype online status is true, then call me to record your opinion for the next podcast.
A Method for results
All methodologies are structural frameworks for a development
process. The process has varying degrees of formality, and various amounts of 'advice'. Typically they are in two camps, light and heavy weight.
All who create methodologies, are keen to demonstrate that their way is best, and of course many are mostly a mixture of good and semi-good principles, with varying degrees of success when deployed within various teams. That is not necessarily because the methods are wrong, as the method may not have been followed correctly, or sometimes conditions just dictate that it will go wrong (ie. probably the people chemistry contributed to it not working. I'll talk about this a little bit later).
Agile Methods has been gaining more ground over recent years, as it is more customer centric and a little more updated from older more 1970's style official office decor.
There are quite a few to choose from, and most who do not follow a certain methodology, are probably following the
Waterfall Model in the larger company or some sort of non complicated model perhaps develop-until-done, in the smaller.
A recipe for failure
Must be more than 13 years ago, I failed at a job interview, because when asked about Booch's OOAD, I replied, "I don't think its the only way to build software, and sometimes its overkill on lightweight systems." -- I really needed that job. But what I believed then is still true. I have been happy to work within the confines and processes of each team and project set before me, but to believe that only one way of doing things will work, is almost, well....religious. (Nothing against Booch, it's the company, not his company, the company that never gave me the job!)
Rather be Agile
In the sense that planning for change. Whether its change of team, change of requirements or change of mind, change will happen, so we need a process that deal with change properly. Unfortunately with current tools and technologies change is hard. Consider requirements, functional specification and other documents, consider tests and diagrams, they are all time consuming when changed. In fact, I don't think many people have been on a large project, without these things becoming out of date and semi redundant. UML was very much like that until recent years.
Being concreted in paperwork, has brought in a lot of good minds thinking about better ways. In our future we have a combination of tools and processes, that will be far superior to anything we have today. I am speaking of Software Factories, Domain Specific Languages and Models, and then the complete process in terms of best practices. Today though we still have some interesting ways of doing things. In the Agile space, we have XP, DSDM Atern, AUP, FDD and others. All offer something similar and in the case of XP, something slightly more extreme.
Dynamic Systems Development Method (DSDM)
There are 8 principles in the DSDM Atern version. (I think Atern is a version name) Whenever I read something on DSDM, I get a sense of the stars. I mean the stars predictions on Capricorn, if read to a Gemini, without them knowing its the wrong write up, would probably agree with it as being their star. It has a classic generalization built into the language, which as a software designer I really appreciate. (at times).
DSDM Atern, Principle 1, states
"Every decision taken during a project should be viewed in the light of the overriding project goal, which is to deliver what the business needs to deliver, when it needs to be delivered."
Now this is a classic generalization that is True, but so is the following description.
"A project is finished when it is finished, and not any sooner, because then it would not be finished."
Principle 2 is deliver on time, 3 is Collaborate, 4 is never compromise quality.
Wait.
From Atern pocketbook, "A solution has to be 'good enough'".
Now thats a contradiction on the title, never compromise quality.
Well the truth is quality is abstract, moving and subjective. I would argue you cannot base a principle on a moving target.
5 is develop iteratively, 6 is build incrementally from firm foundations, 7 is communicate continuously, and 8 is demonstrate control. All of these offer a very simple statement of generalized fact, that will ring true, no matter what. Yes, the business goal comes first, yes I must design and implement quality thats good enough, and yes it must all happen on time.
Other methods are perhaps not as wish washy? Do you agree, disagree? Let me know.
Extreme today may not be Extreme tomorrow
But then in light of DSDM, perhaps extreme may actually give it character and have something good to say. XP
has character, but I think that DSDM has lost a lot from trying to be more business friendly and politically correct. It may be because XP has a few controversial practices which include Pair Programming and Test Driven Development. These are often referred to as controversial or extreme, but in a few years, time will tell if it is or not. The shift is moving rather quickly to Domain Specific Languages, Factories and Frameworks, we may just need to have two minds working on the same models at the same time. It may be common place. But, why not join me on Friday, where we will chat with Mr Kent Beck, the creator of Extreme Programming. (plug - but its my website after all)
So whats best?
"Best", is anything "more than nothing". So even DSDM Atern has its place. It is far better for a team to be collectively doing the same energetic activity towards deadlines, goals and milestones, than a broken, incoherent, inconsistent attitude.
So here are my 3 top reasons why Teams and Projects work.
1. Team work, good positive communication and weeding out trouble-makers, destructive personalities
2. Less is more philosophy, quality not quantity. Document something quickly and to the point, no fluff.
3. Have a good qualified, experienced and malleable leader to help out across
every aspect of a development (including tests, code, database, design, help, review etc).
If you have these 3 things you
may have a good team and project, and any process will be "almost" right. If you have the converse of these 3 things, you will definitely have the reverse result.
I have been in a successful waterfall model project, an unsuccessful waterfall model. I have been in an unsuccessful RUP project, and in a successful one. It is always 70% people, attitude and experience before any process. So before you adopt one, or change one, make sure you have the right recipe within the team to make it work.
The 3 things above are not principles, nor the complete picture, it is "just necessary".
People 70, Methods 30
People, or rather certain personality and environments can breed bad projects.
Typically its my experience that when things get tighter, deadlines get closer, managers tend to want more justification, more proof, more tests, more meetings and more documentation. This leads to an endless cycle, where projects are never given the air to breathe, and the life is then sucked right out. I was unfortunate to be involved in one such development. The stress involved in such a development is usually then accompanied by the PeopleProblem. The PeopleProblem, is when stress lend certain people with certain personality traits to cover themselves and the stress of the project by delving into non project (after-hours) activities, such as politics, whining and other destructive activities. All these sorts of things has lead people to develop more agile approaches. No matter what approach you have, get rid of the destructive members of the team, as they will make any method fail.
Disagree?
Tags: methodology, dsdm, scrum, extreme programming, xp