|Problems? Is your data what you think it is?|
You've just describe (in breif) the waterfall method. As beloved of CompSci faculties and IT departments from the late 60's on. It Was then, Is now, and ever shall be the worst way to develop software ever devised (IM(NS)HO:).
The biggest problem is that the main criteria that it satisfies is based upon flawed metrics--kLOCs, function points etc. Project progress is measured in terms of how much code has been written. That's equivalent to measuring one's progress on a journey in terms of how far one has traveled, instead of how much closer you are to you destination.
You can travel a very long way, and do so very fast, but unless you have regular and mandatory checks to ensure that you are travelling in the right direction, measurements of how far you have travelled are entirely bogus. But even simple checks of progress are not enough. It is entirely possible to complete a journey from A to B by spiralling around A in an ever increasing arc (Archemedian Arc?) until you arrive at B. If you take your progress measurements at inopportune points, it may seem like your making steady progress, and unless you have an overview, you won't see the flaw.
I was required to use this methodology,and still have a plastic laminated reference card outlining the "10 stages of The Project Development LifeCycle" which breaks these 10 stages into 102 substages. I keep it on my wall as a reminder of the "Bad Ol'Days", the mid to late '80's in my case.
I worked on a project that had 1000 developers working at 8 sites across 2 conglomorates in 6 countries. Millions of lines of code developed "To a spec", and then saw the huge mess when they tried to integration test the results.
I'll stick to those bits of the half-a-dozen-or-so methodologies I've seen become the latest fad, and then fade, that made the transition from a rule written on paper, to something I personally found useful enough that I continued the practice even after I no longer had to do it.
As for the term "software engineering". In my opinion, that is an oxymoron. See Re: How do you view programming for an explanation of why.
Your way sounds like it would take twice as long as anyting else.
The whole point of the tip is the idea that you learn to recognise (as early as possible) when you are wasting time trying to 'get something to go', and start again. It's my personal experience that doing anything the second time is easier than the first. I've also found that trying to fix-up a first attempt usually takes longer than starting from scratch. So the purpose of only typing as much in each go as you know will work, and then testing that it does, is designed to minimise the amount of code that you need to revisit at any stage.
Writing code is easy, it's finding the bugs that is hard! So don't try and find them. Throw the bugs away and write again. IME, this gets you to the end of the journey much faster, because you spend much less time retracing your steps.
In the end, this was only my tip, offered on the basis that some might grasp the logic and find it helped them, but like all tips and advice, it's entirely ignorable:)
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.