How Not to do SCM
- When you send out binary releases to customers, don't bother to label them with version numbers, or date-stamps. Or retain a copy of what you sent. Or the source code used to generate them.
- When a customer requests a new feature, or even better a bugfix of an old feature, just fork the project. Make a copy of some (random, unidentified) version of the code base, make the change, then ship it to the customer. What are the odds another customer might request the same change? (And why limit yourself to only one of the infinite possible implementations? Expand your boundaries!)
- Why bother to test. It works in your head, surely it will work on hardware as well, yes? To believe otherwise would to believe your mind is insane, which is unthinkable, so don't think it.
- Fine, so they asked for a manual. Fire up Microsoft Word and give them one. After all, API docs are easy -- just copy and paste the header file into Word and you're there, right? And years later, that old version of the header file will still be there in Times Roman-12, bemusing and perplexing end-users who can't bother to check the source code to see that of course the function signatures have moved on, it's not like we sit on our duffs all day and don't add to the product. So be a good little customer and diff the ASCII header against the formatted Word doc to see what's new. Duh.
No comments:
Post a Comment