1

I am currently implementing an Android application and am struggling to do my class and sequence diagrams, predominately due to the fact that the specifications are too abstract and vague. I was thinking of doing the implementation phase and then to reverse-engineer my work to produce the planning documents.

My question is, is this allowed and advisable?

  • Do I understand correctly that you are asking if it's ok to develop documentation and code as you work through it and understand it better rather than try to document everything up front? – Daniel Feb 3 '16 at 14:53
  • @MarvMills For the record this is project management! I am behind schedule on a project and a potential way was to implement the app first and then to go back to the design phase - but that's ok I know what I am doing. I don't know why I even posted here in the first place when I am going to be greeted like this. – George Blacksonsmitd Feb 3 '16 at 16:06
  • 1
    Don't take it personally, I am just stating facts. If you are working on a project then it is your Project Manager you need to ask, the internet cannot answer this for you, only your Project Manager can. Which also makes the answer specific to your exact organisation and situation, so the answer will be of no use to other visitors. Sorry, – Marv Mills Feb 3 '16 at 16:49
  • Welcome to PMSE, George! I think this question can definitely be salvaged with some judicious editing. The title makes it about development, but there's an underlying question about emergent specifications that could potentially be on-topic here. I think there's a gem of a question here if it can be rewritten to be more about the project planning or sequence of your design phases than about development practices. – Todd A. Jacobs Feb 3 '16 at 23:04
  • I edited your question heavily to make it more of a project management and methodology question. Feel free to continue editing if you feel I've misconstrued the essence of what you're really trying to ask. – Todd A. Jacobs Feb 3 '16 at 23:11
2

Spikes and Prototypes are Okay; Retconning Project Plans Is Not

I was planning to go onto the implementation phase and then to reverse engineer my work.

From a project management point of view, this is not okay. Planning is hard, but not planning creates technical debt and problems for the project and the organization down the road.

Waterfall is about upfront planning. Agile is about just-in-time planning. Neither methodology allows for "ready, fire, aim" planning, which is what you're describing.

From an engineering point of view, it is certainly allowable to do a project spike or create a prototype with minimal planning in order to validate an idea or create lessons-learned for creating a more permanent implementation. However, what you're describing here is more like retconning your planning documents to fit whatever you end up with, which is not a good project management or engineering practice.

| improve this answer | |
  • Thanks for modifying the original question and also answering it for me. It is for a final year project and so I am the manager of it. I am doing it on my own and I was advised to get onto the implementation phase as quickly as possible. I found the planning stages to be depressing and very vague. I just felt that it was a lot easier to model the class diagram and sequence diagram afterwards – George Blacksonsmitd Feb 3 '16 at 23:24
  • 1
    +1 As always you have a way with words CG. "Ready, Fire, Aim!" is going to be reused here (not as a methodology I hasten to add!) :) – Marv Mills Feb 4 '16 at 10:19
1

Another good shooting analogy: shoot, move target over bullet hole, bulls eye!

In the real world, when you have a client to whom you are selling your product, this approach will undoubtedly cause a ton of increased expenses, time, and increased risk of client dissatisfaction. The issue is, many poorly performed projects in the IT space are done in this manner, resulting in a very poor track record of project failures as reported by Gartner and many other sources. If you are experiencing schedule or cost issues already, doing this approach will exacerbate the issues despite how it may contradict your intuition.

If things are ambiguous, get them specified. Spend the time to drill down and document before building. It will pay dividends in the end.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.