No more “shoot first” development…
Published 10.16.2007 by ~mattg
Prior to my current position, most of the development I did was of the “shoot first, ask questions later” style. In other words, people would request a feature with no detail other than “I think it should do this.” I would go off on my merry way and code the feature: design specifications were in my head, adding tables and fields without really documenting them, etc. Then, thinking my work was done, I’d happily turn it over, only to have it ripped to shreds because someone more senior than me thought it should be done differently.
Now is a different story. I’m about a week in to formulating proposed changes to one of our modules. It involves taking suggestions from many different groups, including field engineers, application specialists, and customers, and turning those suggestions into a change list that can be implemented. Once the change list is agreed upon, I have to then create a functional spec which details, on a high level, the changes made and how they will affect the products’ usability.
Granted, the second portion of that involves some initial coding, if only in the form of a proof-of-concept. It is definitely a different process, but one that I have become accustomed to quickly. It’s nice knowing that, when I sit down to do the brunt of the coding, the UI and business rules will have been set forth. In essence, I’m create code based on a solution, not creating a solution based on code.
Filed under .NET Development, Web Development
Yes, a structured, formal definition of a project can really help someone see the scope of the work he/she is doing. This will also afford you a little foresight in to where future changes in the code will be made.
I like the way you put it: “…code based on a solution, not creating a solution based on code.”