Here is the problem, an enthusiastic man wants to build an app, however he only knows roughly how the app should work. There are a lot of details he didn’t know.
How does he design his app?
-Option1:
Do not design, but just code the most important first & test to see how it goes then modify gradually. After the highest priority function finished, he can move to the next priority function. Bottom-up Approach.
-Option2:
Keep thinking until he realized all the details then design a complete app before actually coding. Top-down Approach.
-Option3
Combine of both option1 &2, ie he can design some basic function first then start coding even he didn’t realise all detail then modify accordingly.
It’s very hard to know all the details right at the beginning cos we are human & we can’t predict the future.
So i vote for option1 or 3. But it’s kind of painful if you has to change ur code if you’re missing the details. A lot of things has to be changed. My instructor in university say he always prefers top-down approach cos he believed it better.
However, i think build a software just like u live a life, you never know in advanced what will happen in the future, so option1,3 could be the better one.
What is your solution?
3
What you are describing are different project management approach – Option#2 is a waterfall approach, where you first describe the product, then you design it, then you implement it…
Advocates of Agile software development argue the waterfall model is a
bad idea in practice—believing it impossible for any non-trivial
project to finish a phase of a software product’s lifecycle perfectly
before moving to the next phases and learning from them.[citation
needed]For example, clients may not know exactly what requirements they need
before reviewing a working prototype and commenting on it. They may
change their requirements constantly. Designers and programmers may
have little control over this. If clients change their requirements
after the design is finalized, the design must be modified to
accommodate the new requirements. This effectively means invalidating
a good deal of working hours, which means increased cost, especially
if a large amount of the project’s resources has already been invested
in Big Design Up Front.[citation needed]
Options #1 and #3 are very simplistic descriptions of a more Agile approach, though these approaches tend to be more formal than “let’s hack through it!”
I believe the enthusiastic man should first understand fully what problem he wants to solve. Then, an approach which resembles Option #1 – a Behavior Driven Design – might work for him, where he writes the main User Stories for his solution, describes them, then implements them in short-iterations.
This will produce a quick MVP he can assess, quickly decide if the product is indeed viable, and if it is, start adding more user stories for another iteration…
Most software development involves a combination of top-down and bottom-up approaches. Personally I think it is very poor practice to start coding before you have designed the big picture. You will end up with a bunch of pieces that don’t fit well together. Start by identifying your major components and their interfaces, and how they interact with each other. In OOP you should have all your important class interfaces designed before you start to write code. After you start coding you will surely add more helper classes which just help keep the code neat, but that’s OK. If you program to an interface, not an implementation then you can sculpt out the entire flow without implementing any of the classes. You can start implementing each class one at a time and have the others return mock values until they are ready. This way you always have a complete picture.
As you said, you can’t know 100% every curve ball that will be thrown which is why top-down and bottom-up are used together. Design your program, start writing, and if you need to go back to the drawing board because something doesn’t fit right then that’s OK.
3