If you want to be a success in software development, it's important that you look at other players in the field, and follow their example.
By doing this, I have come to realise that the essential techniques are:
When starting up, write your code without regard to the future - it's important to get the software out the door, and you can always come back and clean it up later.
Later on, when your company has expanded somewhat, don't be tempted to meddle with the existing code, because you may break something. Use this as the reason for leaving it in its unmaintainable state.
As the need for a more professional image arises, instil in your staff a belief in the need for proper design, with design reviews etc. However, there is no need actually to explain to them what this means, nor to check that what you're doing has any benefit. All programmers are fully aware of these issues, and you would certainly just be wasting your time.
If you need a particular function in your current project, you should look around to see whether anyone else in the company has written some vaguely similar code. If they have, then just cut and paste bits of it into your program. Don't worry if you can't really understand it - when it was originally written, the programmer is sure to have designed it carefully, and thoroughly tested it, in all circumstances.
If you can't find the necessary code, then you'd better hack some yourself. Speed is the name of the game here, particularly if your project is in danger of slipping. Just kludge it together, and test it for those situations which seem likely to occur. You can always come back later and clean it up.
If you're a manager, you may be faced with the awkward person who suggests that it would be a good idea if a particular piece of functionality they're designing for their project were actually properly encapsulated, documented, and put into a common library for future use. Don't be put off by this. Point out that the project time scale really doesn't allow this approach this time, and that in any case, it's a somewhat esoteric requirement, that's not likely to appear again.
Use the same argument on the 15 subsequent occasions when the requirement reappears.
Programmers are sensitive individuals, and it's important not to repress their creative urges by suggesting that they're less than competent. To ensure that such a suggestion never surfaces, it's essential that no form of code review ever take place. They're quite unnecessary anyway, since programmers have an innate feel for the best way of doing things, and suggesting that their code be examined by someone else is just plain insulting.
Make sure that the word "bug" is uniformly used, rather than other more objectionable terms such as "mistake", "error", "mind-boggling stupidity". It will not do to give members of your staff the impression that misbehaviour in software is anything other than a fact of life, and something to be tolerated with compassion and understanding.
Cooperate with all other software development companies, to make sure that clients never come to realise that the software they receive could be more reliable, easier to use, or cheaper. Every person who calls themselves a programmer is entitled to receive a professional level of salary, regardless of actual ability, and if customers started expecting value for money, the sad truth is that quite a few programmers would probably have to go onto the dole queue, owing to the fact that they are actually of negative net value in the computer industry.
Go to my home page.