Should I know the complete functionality of my program (i.e. on papers) before I start coding it?
7 Answers
Assumption: we're talking about medium- and large-sized projects.
If you can know the complete functionality of a program before you begin coding phase you are either an eidetic genius or you are working on programs that are simple. This almost never happens in the real-world in my experience (which is mostly large systems). For one, the requirements almost always change along the way, so you would have to be psychic for almost any non-trivial project. However, you should have a good BIG PICTURE of course, you should know the major functionality requirements, but getting into every detail is a waste of time because the requirements will change on you. You need to be in a flexible frame (to borrow a phrase from Joe Versus the Volcano). 'Intuition' about which parts of a system are unaffected by design choices in other parts is an important skill to hone.
One exception might be life-critical applications where the value of exchanging tremendous amounts of time for absolute correctness is necessary. But you would also have to be willing to throw away a lot of work when the requirements change.
In practice, on medium to large projects, I use a more hybrid top-and-bottom development methodology.
It's probably not 'sexy' but the FIRST thing I work on is error reporting, logging, & monitoring requirements. So many inexperienced developers place these as after-thoughts - but they are vital for real-world, critical availability projects. If you give me bad logs I'm going to waste hundreds or even thousands of hours a year debugging stupid problems that should have been trivial. This is going to impact the customers and in turn, your business. Another killer is useless logging. And if you don't get this right up front then every developer is going to do their own thing and you'll have a giant mess that will be too expensive to cleanup.
The bottom-up portion is looking for as many components of the system that are going to be absolutely necessary and can function as stand-alone as possible and write out specifications for those components. String libraries & Math libraries are a good example of these types of components, but you are looking for application domain cases that don't already exist (of course you look for existing libraries where that makes sense). You are looking for cases that don't require knowledge of OTHER parts of the system to be written. These components are the easiest to spec out, the easiest to test, the easiest to get correct, and the easiest to tune for performance where needed (measure first, tune second - you can be excused from this if you are hand-machine coding the inner loop of a fractal computation loop, tune away). These are also good candidates for outsourcing or more junior developers.
The top-down portion is thinking about the problem in terms of some set of application domains. I want to sketch out code that matches the way I want to naturally talk about the problem and then I want to build the API, flesh out the internals, and use all my nice, compact libraries.
Treat this phase as proper language design and you will be rewarded with an expressive solution that is flexible enough to follow the solution through the many changes most projects face during their life-cycle. You want to build a suite of tools you bring to bear on the problem, not a monolith. But the danger here is going too far, too generic - you have to find the right balance and make compromises based on your judgement (and avoid the Turing tar-pit in which everything is possible but nothing of interest is easy).
35+ years, Pascal, 9900, 6502, Z80, PowerPC, Forth, C, C++, Perl, Awk, TCL, Lua, JavaScript, Java/Groovy - I've worked on kernel, heavily networked applications, command-line applications, web-based solutions, protocol design, large & small systems, low-level firmware & system bring-up, and embedded systems -- at both large and small companies.
Currently disrupting the supply chain industry with innovative uses of TLAs and Buzzword repetition.
Of course. You need to fully understand the requirements of your project so that you can properly design your program before you code it. Otherwise, you're prototyping your application with experimental ideas and your program may be sloppy in terms of design and implementation. However, it's not uncommon to turn an application prototype into production software by careful refactoring and code review.
Comments
Post a Comment
Comment here.