Building Quality
These last 2 months have been a fair approximation to hell on earth. As a result, I've decided to go on a mission.
Those who pay attention to me at work may have noticed that I LOVE standards. Well, I actually hate them. But in a professional environment I have seen too many times first hand the end results of not adopting and respecting them, as a result, I appear to love them.
An area oft overlooked for standards is the development process. These last 2 months have been hell, because I have been involved in a project on a tight dead line which has no standards or set methodology. And, since I'm sick of being stressed, I'm hoping to improve the company. And I'm going to do it by re-writing Veronica's application and hopefully using my findings as a platform to inject a proper process for development.
To do this, I'm going to need a couple things. Firstly, I'm going to log ALL of my time spent on this project during each phase so I can correctly translate this into the number of man hours spent in each type of work. And secondly, I'm going to choose a well established and well defined design methodology and follow it as precisely as possible. Hopefully, at the end of this I will be able to present a strong case for adopting a well defined methodology by showing that resources can be used more efficiently with proper planning (it actually feels a little infuriating to think that this last sentence might actually require someone to prove it to get it done).
For the purposes of this project I have chosen the Extreme Programming methodology as discussed here. XP is an agile programming methodology with very well defined processes. I cannot comply with the pair programming or rules of XP that necessitate a group as I am a single individual, but otherwise, I will follow this like a religion for this project, so perhaps it is better to say I'm utilizing a modified XP approach so I don't aggrivate any purists.
I will be tracking time, specifications, and doing any documentation related work on my iPad, though I will try and report back here regularly as well. The advantage of the iPad is that I have essentially a second monitor with that information while I'm coding, instead of keeping that information on this laptop and switching windows or running Visual Studio windowed, which given my screen resolution would be a nightmare.
I guess the last thing to talk about is why I think it is needed based on this most recent experience. The biggest issues that we are continually scrambling over are holes that were present in the initial design. These aren't scope changes, these are things that were scoped and either X didn't agree with Y or one of X or Y simply wasn't completely scoped. Things which should disappear in a properly planned project. Our second biggest issue would be wasted efforts. Some effort was wasted as a result of the prior point, but more simply as a result of being unable to notice re-usable elements within the code. Something which we would have been able to spot if we had simply painted a picture of what we wanted before we started trying to build it metaphorically speaking.
At the end of the day, having a design methodology is the difference between programming and software engineering. Like an engineer, the only way to plan for success is with plans and blue prints and standards to enforce them. Without them, you may get the job done... eventually.
Those who pay attention to me at work may have noticed that I LOVE standards. Well, I actually hate them. But in a professional environment I have seen too many times first hand the end results of not adopting and respecting them, as a result, I appear to love them.
An area oft overlooked for standards is the development process. These last 2 months have been hell, because I have been involved in a project on a tight dead line which has no standards or set methodology. And, since I'm sick of being stressed, I'm hoping to improve the company. And I'm going to do it by re-writing Veronica's application and hopefully using my findings as a platform to inject a proper process for development.
To do this, I'm going to need a couple things. Firstly, I'm going to log ALL of my time spent on this project during each phase so I can correctly translate this into the number of man hours spent in each type of work. And secondly, I'm going to choose a well established and well defined design methodology and follow it as precisely as possible. Hopefully, at the end of this I will be able to present a strong case for adopting a well defined methodology by showing that resources can be used more efficiently with proper planning (it actually feels a little infuriating to think that this last sentence might actually require someone to prove it to get it done).
For the purposes of this project I have chosen the Extreme Programming methodology as discussed here. XP is an agile programming methodology with very well defined processes. I cannot comply with the pair programming or rules of XP that necessitate a group as I am a single individual, but otherwise, I will follow this like a religion for this project, so perhaps it is better to say I'm utilizing a modified XP approach so I don't aggrivate any purists.
I will be tracking time, specifications, and doing any documentation related work on my iPad, though I will try and report back here regularly as well. The advantage of the iPad is that I have essentially a second monitor with that information while I'm coding, instead of keeping that information on this laptop and switching windows or running Visual Studio windowed, which given my screen resolution would be a nightmare.
I guess the last thing to talk about is why I think it is needed based on this most recent experience. The biggest issues that we are continually scrambling over are holes that were present in the initial design. These aren't scope changes, these are things that were scoped and either X didn't agree with Y or one of X or Y simply wasn't completely scoped. Things which should disappear in a properly planned project. Our second biggest issue would be wasted efforts. Some effort was wasted as a result of the prior point, but more simply as a result of being unable to notice re-usable elements within the code. Something which we would have been able to spot if we had simply painted a picture of what we wanted before we started trying to build it metaphorically speaking.
At the end of the day, having a design methodology is the difference between programming and software engineering. Like an engineer, the only way to plan for success is with plans and blue prints and standards to enforce them. Without them, you may get the job done... eventually.
Comments
Post a Comment