Starting a New Software Development Project or Task?
Most Software Developers, including myself, want to just dig in and start writing code. You understand the problem and you have a solution (all in your head). Time to write code!
Code is written and you've tested the solution and it's working perfectly. You're happy!
You set up a meeting with the Quality Assurance person or team... They take notes and test it. They're satisified and it's working as it should. So, it's deployed to Production.
A week later, a bug was uncovered... No problem just fix the code.
Now the program has been running flawlessly in Production for a couple of years and still meets the business needs perfectly. You're proud of your efforts and you should be! That's impressive!
While most can do a good job in getting the task at hand done in this manner, going back at making code changes to a project that you haven't hardly thought about for a long time, and started this way , is tough! You may even ask yourself, did I write that?... Hopefull, you don't say, "This is terrible, who wrote this!"🤣 ¯\_(ツ)_/¯
Why would you ever do that? Everybody knows you need to document first! It's because you committed to a timeline in your sprint and your goal and what your paid for is to meet that deadline!
So, how do I spend all that time documenting everything and still get the project done in time?
I believe the answer is Spend the time! Put documentation time into your time estimate.
How should you start a project? Five simple steps:
Steps 1-3 all can be done through the evolvement of a diagram... And nowadays, the tools to do this are fantastic and will only get better.
My favorite tool for this is draw.io, now app.diagrams.net. This tool is free! And I love it. Here's a sample diagram: Browse the blog for more helpful tips and thoughts and look for more to come...
Code is written and you've tested the solution and it's working perfectly. You're happy!
You set up a meeting with the Quality Assurance person or team... They take notes and test it. They're satisified and it's working as it should. So, it's deployed to Production.
A week later, a bug was uncovered... No problem just fix the code.
Now the program has been running flawlessly in Production for a couple of years and still meets the business needs perfectly. You're proud of your efforts and you should be! That's impressive!
While most can do a good job in getting the task at hand done in this manner, going back at making code changes to a project that you haven't hardly thought about for a long time, and started this way , is tough! You may even ask yourself, did I write that?... Hopefull, you don't say, "This is terrible, who wrote this!"🤣 ¯\_(ツ)_/¯
Why would you ever do that? Everybody knows you need to document first! It's because you committed to a timeline in your sprint and your goal and what your paid for is to meet that deadline!
So, how do I spend all that time documenting everything and still get the project done in time?
I believe the answer is Spend the time! Put documentation time into your time estimate.
How should you start a project? Five simple steps:
- Define the Problem. First, know what the result should be. Then what input do I need to get that result?
- Plan the solution... Yes, even in the year 2100, this will still be needed!
- Code the solution. (Yes! This is what I love to do!)
- Test the solution.
- Document the application.
Steps 1-3 all can be done through the evolvement of a diagram... And nowadays, the tools to do this are fantastic and will only get better.
My favorite tool for this is draw.io, now app.diagrams.net. This tool is free! And I love it. Here's a sample diagram: Browse the blog for more helpful tips and thoughts and look for more to come...
Comments
Post a Comment