If you got tired of all the D
hingThatCouldPossiblyWork, or if you are a beginner who wants to program stuff before putting tons of useless ideas in your head, then forget about all the principles that you are taught, and write a good program.
Without the principles, is it likely to be a good program? With them?
With all due respect to all the various buzzwords we bandy about, my philosophy tends to be to:
, or something like it; but I tend to phrase it as
- ImproveMercilessly? (which includes RefactorMercilessly, doing LargeRefactorings without fear, and OptimizeLater - as opposed to OptimizeNever?).
I see that and raise the abstraction to: I just write programs. The devil, of course, is in the details. -- JoeWeaver
To use a Star Trekism: MakeItSo
Sadly, all these discussions completely ignore the need for process in the creation of a working product. Process is not an end-all, be-all of its own, but it needs to be there to insure that you are creating a good product that meets requirements.
So that means you have to start with requirements (CategoryRequirements
). You refine these into a specification (WhatIsaSpecificationAnyway
), which formalizes the requirements into a set of measurable criteria that you use to determine if the product is good or not. Then you create an architecture (CategoryArchitecture
) defining the components of the product, the services they provide, and those services' interfaces. Once you have an architecture you then need a design (CategoryDesign
) that separates the duties of components into hardware, software, electromechanicals, myth, legend, and vapor. Finally, after all that stuff, you get to the implementation (ImplementationDefined
). Then you can talk about code.
Extreme Programming is the shortcut to all this stuff that goes directly from a client's babblings to "working" code. If you are building a product where this is possible then gofer it. For most of the world, however, you need some process in place to avoid moving goal posts in terms of product performance.