Sunday, October 03, 2004

Not Invented Here Society’s (NIHS) Best Practices

  • Don’t write code that can be shared between more than one project – there’s no job security in that. Hiring more software engineers is good for the economy. Don’t even look for an existng solution to your problem—that’s like admitting you’re incompetent.
  • There’s no bug-free technology. We actually believe in inventing a lot of very difficult bugs. We find it keeps our debugging skills sharp and QA doesn’t get complacent.
  • Keep irregular work hours – it looks much better to management if we stay until 8pm every night. No one notices we drag in around 11am, take lunch at 11:30am, play games from 3-4pm, hold the fantasy football trade meetings from 5-6pm, and eat dinner from 6-7pm.
  • Constantly complain about long hours and the ‘sweat shop’ environment at work. Suggest a task force be formed to study why each project ends in ‘crunch mode’. Make sure you or another member of the NIHS is on the task force. Your job is to direct the investigation away from the fact that many bugs are created for each line of code written. Instead, talk about the constantly changing requirements and lack of ‘resources’.
  • If you ever hear rumors of executives thinking about external technology, it’s time to mobilize the troops. The key phrase here is ‘executives thinking’…it’s an oxymoron. Make your fellow programmers aware of the situation-- the idiots are at the gates again, trying to destroy your beautiful creation with cheap imitation software that doesn’t even follow internal coding standards. If that doesn’t get people going, tell them the next step is to move their jobs to India, or even worse, Indiana.
  • Fight metrics at every turn – you can’t measure the art of programming, you can’t quantify programming productivity, so don’t let anyone try. If a manager asks you to estimate a task, make sure you pad for debugging time (got to create those bugs), ramp up time (try to use a new language or API whenever possible to maximize this parameter), code review time (focus on style not logic), mentor time (teach new programmers to obfuscate their code properly), and refactoring time (don’t do anything right the first time, programming is an iterative endeavor).
  • Remember, program managers are like mushrooms—keep them in the dark and feed them bull shit.