This means:
- Interview the project manager (the person responsible for the success of the project) for the story.
- Convert this story to requirements.
- Present the project manager with the requirements.
- If approved go to the next level.
- Do a High Level Design (HLD)
- Present this HLD sidelong the requirements and estimate roughly the solution time in human days labor.
- If approved go to the next level.
- Breakdown the HLD to low level design (LLD).
- Estimate LLD and present estimated more accurately time in human labor.
- If approved go to the next level.
- Implement the LLD and stick to it (no time for adventures).
- Do unit test, system test as much as i can (depends, sometimes not possible).
- Present a working machine.
- Be happy and relax.
This time, everything went wrong! Why?
Here were the flow of things:
- Pressure to implement as fast as possible (reasons: no time, no budget).
- I broke and agreed to 'be fast'.
- Skip HLD + LLD, start implement! ==> no thoughts of risks, everything looks easy when you don't think about it deeply.
- Implementation got some problems I didn't see in advance (and frankly, none can think that deeply).
- More and more problems arose ==> delivery time breaks ==> more pressure.
- No one is happy, all is waiting for the delivery => more pressure ==> shorter code, less secure code, BAD CODE!
- ... The test-bench is too complex to operate... Catastrophic :-)
Next time - Do it right!
If the project manager don't want to do it right, ignore him :), take your time, design it, show him the design, say 'i thought about it and found some problems' (when doing the hiding HLD + LLD).
You only get an advantage in the start, when things get rough (and they do!) you will cross the break-point and start to be slow (because you can't load all the HLD into your head).
In the end the project worked, the code, barely, but did managed to work, the time for this project took much longer then 'fast and short' (twice if not more the time it should take), and a bad taste was in the mouths.
