The Best Software Development Process

I've seen this pattern over and over again in almost every programming shop I've worked in. A group of people take it upon themselves to "improve" the software development process. Sometimes they would attend a workshop, or read about some magical system that promises to fix all problems in developing software. These would normally entail imposing some rules and system that the programmers are supposed to follow, and everything will be alright. These systems come in various names such as "ISO 9000", "Rational Unified Process", "UML" "CMM Certification", "Extreme Programming" and other names too numerous to mention.

Managers and non-techie types are usually delighted to enforce these procedures to keep programmers in check and make them replaceable. Some of these systems even have some rational basis but end up being perverted to some form that has little resemblance to the original intent. It even manages to fool some of the programmer types who are sick and tired of missed deadlines and failed software projects and are desperate to try anything new.

Based on my experience, these systems always end up doing more harm than good, and they always make life more difficult for the programmers. Worst of all, they shift the power over to the managers, requirements analysts, and non-techie types - power that should be in the hands of the people developing the software in the first place, the programmers. I never liked these systems and I never will. Why so? Because I believe that the best and most practical decisions should be in the hands of the software developers. The best system for making sure a project will succeed is by getting the best developers for the job, and giving them the freedom and leeway to do what is best for the project.

Systems such as ISO 9000, RUP, XP, and its ilk are an advantage only if you treat your programmers like livestock that can be easily disposed of and replaced with new pets. Or if you don't trust your developers to be good enough to do the job, so you impose lots of rules and restrictions to make sure they don't mess up. It's like playing not to lose rather than playing to win.

What you want to do is to get the best developers to be interested in their work and love the project. Then they will give their best effort and make tremendous sacrifices to produce the best quality code possible. Ideally, you get a couple of great developers with lots of experience in writing good software in the past, then combine them with good, young coders who lack experience but are eager to learn. That for me, is the best software development process.

Plus, it's more fun too. I want my work to be fun. I don't want my work to be like work.

History of Wordstar

Here's a fascinating article by John C. Dvorak on the history of Wordstar. I still remember typing old term papers, school research using Wordstar on an IBM PC compatible back in high school. At the time I was probably only one of several students who actually used a computer for schoolwork. And I remember our teacher even tried to ban us from using a computer and force us to use a manual typewriter instead because she thought using the computer was "cheating".

Nowadays of course, everyone uses the computer. No one uses a manual typewriter. And hardly any of the kids will remember Wordstar, the first popular word processor.

How to read a How To book

How-To books are books that guide you to train yourself in a specific skill, or improve yourself in a specific knowledge area. Reading them is one of the best investments you will make.

Here are some tips on how to read a How To book:

* Read in the bathroom - Keep a book or two in the bathroom and read a couple of pages or chapter every session. I actually finished several books over the course of a month or two, all in the bathroom!

* Don't feel compelled to finish a bad book - If a book starts out good but turns bad in the middle, or if it stops providing you real value in the middle, don't feel guilty about not finishing it. Just get what you need and move on.

* Don't be afraid to call a bad book a bad book - If you discovered you made a wrong judgment as to the reading value of a certain book, don't feel too bad. Just dump the book and move on, no sense in wasting more time and money by reading it.

* Skip around - Not every book needs to be read from cover to cover. Some of the best books I've read, I've skipped from chapter to chapter, reading the most interesting parts first, until eventually I discovered I actually went through every page.

* Read it twice - For truly great books, such as those that are revolutionary and result in drastic improvements in your life, read them twice to make sure you absorb all the ideas. I've read each of my most favorite books of all time at least twice.

* Share it with a friend - Read a good book? Tell a friend about it. Buy one for him if necessary if it really is that good.

* Don't rush - Never go through a book in haste wanting to "get it over with". If for one reason or another you find yourself rushing through one, take a break, put a bookmark, start reading something else until you can devote your full attention to it.

* Read while commercials are on - Better to skip the bad TV programs in the first place (or avoid using the TV as a "time-filler"). But if you do watch TV, particularly pro sports like basketball or baseball, you can get a lot of reading done during the commercials. Sometimes the book becomes more interesting and you continue reading even when the commercials are over.

* Do not read beauty magazines, they will make you feel ugly - Just kidding, I just copied that line from Mary Schmich's classic essay 'Wear Sunscreen'.

Happy reading.

When to do abdominal exercises

Here are some tips you can do on your own to develop your abdominal muscles which is the foundation of having greater core strength. No need to join a fancy gym or buy any expensive equipment. Just do the basic ab crunch while doing the following activities:

* While flossing or brushing - keep the ab muscles tense while flossing or brushing your teeth.

* While waiting for the program to compile - use a fitness ball or stool to do a few crunches while waiting for your program to compile (or any lengthy computer processing activity where you have to wait).

* While watching TV - do crunches while lying on the couch or at bed while watching TV.

* Use the 10-minute rule (courtesy of lifehacker) to sneak in a few ab exercises when you're not in the mood to do any exercise.

Lastly, and this is my principle in any exercise, avoid narcissism while working out. When exercising, your objective should not be to make your body look more attractive. A better reason for exercising would be to feel better and get the body operating more efficiently. Too often we workout as a means of enhancing the ego, which will frequently backfire in the long term.

Talking to Yourself

"It's strange calling yourself..."
- Naomi Watts, 'Mulholland Dr'

"Now you will see me one more time, if you do good. You will see me, two more times, if you do bad. Goodnight."
- Cowboy, 'Mulholland Dr'

Welcome! We are lifelong students with a love for learning and self-improvement. We believe that knowledge should be shared and celebrated. We seek to acquire new ideas, as well as share some tips that have helped us in the past. We hope you will be entertained and enlightened while reading dangerous students.

Here's a quick coding tip on how to more effectively use source comments. You add comments to your code to document some behavior that is not immediately obvious while browsing the code. Comments also help when other programmers read your code.

But for me, the most important use of comments is that it is a way of talking to myself while I am coding. I like leaving messages to my future self when writing code. These are breadcrumbs I leave to guide me the following day, telling me what parts of the code I need to review, or what are unfinished sections that I need to complete. Here's a sample:

// area = pi * r^2
double GetCircleArea(double radius)
{
  // $$ Move pi to constants section?
  const double pi = 3.14;

  // $$ how about negative radius?
  return pi * (radius * radius);
}

void main()
{
  double r = 2.34;
  double area = GetCircleArea(r);

  // $$ todo: localize string
  Console.WriteLine("Circle area is " + area);
}

I talk to myself when I code through the use of comments prefixed by a searchable key word. Sometimes while I am writing lines, I realize that I need to handle the logic another way. Or do housekeeping stuff such as moving literal strings to a resource file. But I don't want to lose my train of thought, so I place a marker to remind me, and move on.

Then after I test that the core logic is working. I search through all instances of "$$" in the source file and proceed to handle those error checks I failed to do. Or do no-brainer stuff that I didn't want to be distracted with previously.

Sometimes I leave the $$ stuff for days when I am blocked mentally and can't think straight. That's the best time to do the boring, menial housekeeping coding work. You know the code is complete when all the '$$' reminders you set for yourself are gone.

This is also useful when you need to ask another programmer's opinion of your coding implementation. You check in the file with the comments, and he reads through your messages/reminders, then gives you feedback or even implement some of those sections himself.

So comments are actually useful, not just for commenting the code but for talking to your future self while you're writing it.

Dangerous Students

Dangerous Students - computers, math, puzzles, tech tips.