Okay so here goes- I have reached out to that good old publisher (O’Reilly) that brought the ‘Head First’ series into my life for an insight into the subject of software development…and I am going to use it as a guide- get me thinking of the right things, and equally so prevent me from doing the wrong things, and help me move in a structured fashion to produce the kind of quality artifacts necessary to complete a successful project.Once again I want to digress for a second, and just say from a software development / programmatic novice’s perspective, how refreshing it is to have a series of books like the ‘Headfirst’ series. I am hooked- truly!! And it would be my recommendation that anyone wishing to take a leap of faith into the unknown does so clutching one of these books.
Lets make no bones about this, I am not a experienced developer, I have very limited experience in art of software development, and I find that most books present the subject in such a dull and boring fashion that I am asleep or irritated after the first few chapters. This however is different…and I am loving it!
Okay so what are the initial landmines that I need to dodge:
Mmmm not so much for this project, but in a real world scenario definitely!
A B S O L U T E L Y….and for those that cant see me right now I have just turned a pale, sickly, shade of grey. Time is a difficult one, as I have mentioned several times in the posts that precede this one…and let me use an analogy to help clarify my position: Imagine you are asked to drive across the country to a particular destination, at night, without a map (Google Maps these days..lol) or compass (now I am showing my age), and having barely learnt how to drive??? It is a tough call to determine how long that would take…do you see what I mean? All the best laid plans in the world could amount to nothing.
O’Reilly does elaborate on the ‘Big Bang’ approach to software development, which essentially amounts to taking on a project, documenting the requirements, and going ‘dark’ until you have the finished product- and then giving the customer the first glance at what you have produced. I can see how this would cause issues, and I can most definitely see how you could miss achieving the customers requirements…it is an interesting thing perception, because perception is by and large determined from an individual or group perspective, and if my experience has taught me anything it is that if you leave someone long enough, that perspective changes. To bring it all together I guess what I am trying to say is that documenting a customers requirements, and even mapping them, verbatim, to a software application, without any consultation along the way, may still be an unsuccessful endeavour!
People change, as do perceptions, and so to will the requirements of any project.
I truly appreciate the O’Reilly perspective that the success of a software development project depends does not depend on fancy development processes, but rather finding a process that work for you, and assists in producing great software- on time, and within budget. I guess that is the essence of most successful people, not that they do things exactly by the book, but rather they find what works for them and they do it well.
So far the guiding principle that I am going to use in my development process is going to be that of regular ’I - T - E - R - A - T - I - O - N’ . Considering my experience I need to make sure at all costs that the project stays on track, aligns to the customers requirements, and that risks are identified and mitigated early on. My project need to be built on an established platform!!!
The way I see myself achieving that is through the following process:
- Through decomposition breakdown the requirements into modular blocks
- Identify dependencies and the natural sequence of events
- Prioritize
- Tackle each of them in turn iteratively- designing, coding, and testing.
- Reviewing each deliverable in turn with the customer
- Their verification and validation against the requirements specification will signify that I can move onto the next module
I am going to steer clear of putting any specific time delimiters against the modules for now…obviously I am still learning C#, Visual Studio, and getting to grips with the .NET classes. Furthermore I may change my customer review periods as the project evolves- depending on what feels right for the project….and so long as I don’t jeopardize the project.
Next step…lets map out those requirements!!