Recently I found myself coding less and “planning” more. It took me a while to work out why, and when I did I thought I would write this so that others may avoid the trap I was in.
Firstly, some background. As you may or may not be aware, I am writing an API in java for read an OData source. Now, I am using TDD principals to code the API (basically write a test case and then write the code that makes this test pass). This means that I need to think in small increments, write a test for the small increment, then write a small increment that satisfies that test, then write another test for another small increment, then write that small increment and so on, you get the idea.
Now back to the present. I encountered the next part of my code requirements, implementing XML namespaces within my code. This is where my problems started. I did the right thing by researching some things on XML namespaces, to make sure that I understood how they were implemented and make sure my code didn’t vastly differ what it should be. Then I did the wrong thing, I tried to plan the entire implementation of the XML Namespace component, rather than looking at the small piece I was dealing with (in this case pulling the namespace and storing it in the required format).
I was planning the reading dtd and metafiles and how that would work. Looking at the manner that dtd’s could be delivered. How would I know which was an internal namespace and which was an external? How would I register the external namespace in my code (for example the $metadata of an OData source)? And so on and so forth. That is not how I am wanting to write my code. I want to write a test for a small part, then write that small part. In this case the small part was identifying the namespaces and putting them into a useful format.
This got me thinking about agile and waterfall practices. Agile methodologies would say that you get the requirement and break it down into smaller pieces, and those into smaller pieces until you have something that can be done in a defined period of time (for example, in scrum you would break it down into smaller pieces that would be done within an iteration). Whilst you know what the requirements are, you don’t design the entire solution for what may or may not happen, nor do you plan everything out at the start. You break the requirement into smaller chunks and that into smaller chunks into a requirement that you can complete within a week or 2.
Waterfall is very different to this. In the waterfall approach, you define every requirement that you can think of, plan the end result to the finest detail, then you start coding to the fine details that you have planned to deliver. You don't start coding until you have the UX defined, the web services documented and the classes worked out and what each class properties and methods are.
Now, without going into a discussion about waterfall vs agile development practices, I will say my thoughts. While there are parts of one in the other and vice versa, the two can not coexist. For example, when your doing agile you need to know the end result, what is the stakeholder asking for. That you can break down into smaller requirements and so on until it is small enough to complete in iteration or sprint. And conversely in waterfall development, you can not say “deliver the whole project at once”, you need to break it down into smaller chunks that a developer can work on.
The main point of difference for me is that in my opinion, agile is about meeting the requirements that you have been asked to deliver. No more no less. You cant tell the stake holder what they want, you can only guide them along as you code and as they see the work. This doesn't mean that if they say they want a field you don't do any error checking on it, or that you just make it work and not deliver a quality product. What it does mean is that you don't enlarge the requirements to what you can see being needed down the track. You meet the current need. If the database table needs a title, description and timestamp, don't add a link to a status that is then part of a different requirement. By the same token you can guide the requirements along by asking questions like “where is this going to be reported?”, “Is there a need to report on this?”, “ Who should be able to edit this?”
Waterfall projects on the other hand you can vastly change the requirements because you are part of the planning process. Nothing gets done until everything is defined and some form of specification documented. You research to make sure that it is future proof, so that you can work on another project and this one wont need any attention. You tend to guide the requirements and specifications, rather than the development. But, once it is locked in, it takes a lot to change one line of the specifications that your working to.
Personally, I prefer agile development processes over waterfall process because you can be flexible, if you code something that the user changes their mind on you can adapt. (Hence, why it is called agile.) You also only deliver what is needed, not what you think is best. The issue with stakeholders is that they don’t always communicate it well to developers, project managers or product owners. Hence the need to ask questions and listen to the answers. You also end up with leaner code (it does what is needed, and nothing it doesn't) rather than bloated code with parts that are rarely, if ever, used.
No comments:
Post a Comment