Process Based Development

I have come across recently a way of developing software in an “agile” way. Stories are written, encapsulating some functionality and subsequent stories enhance or build on those areas. They are tested and deployed for review during and at the end of the sprint. Everything is working as you would expect. You work on a process till it is “finished”.

Is it really finished though?

However, what if there are dependant processes down stream? Can we say that the 1st process is done? It is like wiring a house without ever checking that switch A turns on light A. You wait till the whole house is built and decorated before finding out a) it isn’t finished and b) you need to make a hole in that wall to get into the wiring again. (I don’t know if this is strictly how you would fix that issue, i am not an electrician! Hopefully the analogy holds though).

An alternative process would be to develop part of the 1st process, then implement it’s usage in process B to verify a) it works and b) assumptions on it’s structure/format/workflow are correct. For instance we have a process to define some business rules, set parameters, data to be used in another process. We then implement a basic usage of those business rules to show them being applied and verify that amending them gives us the desired results. This is kind of like Unit Testing (or even Test Driven Development) for the application from a end to end point of view. We write enough code to add or edit some of these business rules, then enough code to test that their usage is correct. We can keep iterating over this adding more features and testing their usages.

This approach can catch unexpected behaviour and quickly highlight where additional refinement or changes need to be made. We also have a fully working system (basic at first, gaining more business value over time).

Estimation

One of the problems with estimation is it is a “best guess”.  At the initial conception of the project we know the least about the requirements, solution and possibly even the platform or language we are using. So we use past experience and gut feeling to decide how long we think it will take to develop the application. If we are concientious then we will probably use a best, likely, worst case estimate and be honest towards which end of the scale it is going to be. Remember it is an “estimate” not a definite deadline.
Other professions over estimate and complete early based on estimate, we recently had some wardrobes fitted and the company doing it told us to expect it to take 2 days, so we could plan to leave our room in a state they could work in for that period. Upon starting the work i asked the fitter about this and he said

They always book us for 2 days, but it only ever takes 1 and a half at most

Surely this is just good practice, the fitter is able to spend more time if he hits a snag and the customer/client is not misled or disappointed. They have estimated on the worst case and allocated this time accordingly.

Does this happen in the software industry on the whole? Please feel free to comment on your own experiences.