There's two lines of thought when it comes to engineering process. The first one says that all aspects of a computer program should be extensively defined and documented prior to sitting down and writing the first line of code. The second one says that customer needs will change over the course of the lifetime of a program, so instead you should focus on building a general infrastructure that can be easily modified to match customer requirements over time, rather than on defining exactly what the program is going to do and how it's going to do it.
What I'm finding is that, as my team's experience builds up, I need to do less and less of the "extensive definition and documentation" bit. Instead, we do high level functional and architectural discussions and documentation, maybe do an outline of the general architecture and what the main modules and classes will be and the interactions between them, and there we go. When my team was greener, I had to do detailed documentation of each class and each method as to what it would do and how it would do it and what its parameters would be etc. Now, other than when we're interfacing with each other's classes, that's no longer necessary -- the guys "get it", and a general description of the class and the business problem it's supposed to solve followed by a few emails clarifying various points of possible implementations pretty much solves the problem.
Some folks once criticized me for saying that if you gave me four of the best people I've ever worked with, we could out-program a team of 200 outsourced Indian programmers. But thus far I've not seen any reason to budge from that statement.
-- Badtux the Computer Geek Penguin
As one who worked to 'break' others code, make sure you test, test, test, and test again. A program always works as coded -- and that is where the problem lies. What you write, and what happens when humans get to use it, may not be what was wanted, nor intended.
ReplyDeleteI don't see any reason for you even bothering with it. Go camping.
ReplyDeleteDon't forget "build for testability". If you are writing an object oriented program (which you should *always* be doing), always write "dummy" modules to take the place of modules that you call, and test the module you're currently writing to destruction using the data from those dummy modules. This also prevents you from writing objects that "reach into" other objects and have carnal knowledge outside the API of low-level details of what that other object is doing. The best place to put reliability is in the software itself, not as some external thing. You can't "test in" reliability if your software itself is inherently unreliable with objects that have carnal knowledge of other objects, no testing for memory leaks and buffer overflows, etc.
ReplyDelete- Badtux the Computer Wizard Penguin