All I really need to know about Software Development I learned from TopCoder
Thursday, April 29, 2004

By dplass
TopCoder Member

Introduction
With apologies to Robert Fulghum, here is my interpretation of TopCoder being a microcosm of the Software Development world.

1. Well-worded problem statements can make a big difference.
   A clearly-written problem statement allows the coders to internalize the problem easier and start coding faster. A variety of examples help you figure out what was meant in the prose. Part of this round table thread discusses this exact topic.
   
   In the "real world", a good requirements document, or a well-written specification, is worth its weight in gold. The designers know what to design, and can hand the coders a more complete design as a result. Confusion is reduced, and re-work can be eliminated. The guess-work is taken out of coding and the coders can complete their job with fewer bugs.

2. Think before you code
   During an SRM, instead of just starting to hack away at a problem, I stop and think for a minute or two, or ten. I take notes and maybe jot down an algorithm. This has definitely helped me improve. The same thing applies in software development. Take a moment to write down what you're going to code before you code it. Show it to someone so they can review it and, in some companies, approve it, before you code.

3. Test early, test often
   TopCoder SRMs are notoriously insensitive to bugs. You should start testing even before your code is complete! Sometimes, especially on a medium or hard problem, I'll write a section at a time, and test it as I go along. Also, don't just test on the "samples" - you should run as many possible test cases as possible. One failed system test case, and you're sunk.
   
   A major tenet of Extreme Programming , a very popular software development paradigm, is to test, test, test. You are advised to write the tests BEFORE you write the code! Another variety is called "Test-Driven Development," in which each phase of development is driven by its own testing phase.

4. Test your code or someone else will test it for you
   Ah, the challenge phase. Having recently been burned by this, I can attest that the more you test your own submissions BEFORE you submit them, the better. Otherwise, someone else will find that elusive (or maybe not-so-elusive) bug and pick up 50 points in the process. Had I just remembered to write ">=" instead of "==", I might've gotten those 216 points. Instead, someone else found it, and I'm out.
   
   In the "real world", the last person you want to test your code is your customer. When a bug is exposed by the end-user, it's worse than just losing 216 points. Your company's reputation is on the line. Your competition is ready to pounce at the first sign of weakness (hmm, sound familiar?) Not to mention the potential lost sales might result! Testing is one of the fundamental tenets of many software development methodologies (see above, "Test early, test often").

5. Finding a bug during the coding phase is cheaper than during the challenge phase, is cheaper than during systest
   If you find your bugs during the coding phase, and submit the solution for, say, 200 points, you'll get 200 points. If someone finds it in the challenge phase, you'll be out 200 points, but at least someone got 50 points for it. The overall "benefit" to society is 50 points. However, if nobody finds the bugs during coding OR challenge phases, you'll be out 200 points, and nobody will get the 50 points. The overall "benefit" to society is zero.
   
   In software development, it has been proven time and again, that when bugs are found earlier in the process, the better. Finding a bug in one phase can be 5 to 10 TIMES cheaper than finding it in the next phase. Finding a bug during requirements is 5 cheaper than finding it in design; finding it in design is 5 times cheaper than in coding; findng it in coding is 5 times cheaper than in testing, and finding it in testing is 5 times cheaper than in production. This effect multiplies - so if you squash that bug in requirements phase, it is 25 to 1000 times cheaper than finding it (and fixing it!) in production.
   
   So fix those bugs NOW!

6. Spelling counts
   A spelling error cost at least two coders the "easy" Div 1 problem, in a recent SRM. They spelled SQUIGGLE wrong, and it cost them points.
   
   When you're writing code, sometimes the only person reading it is you. The occasional typo doesn't affect the operation of the program. But, when developing a website, or end-user software, spelling counts! If you spell your client's name wrong, they'll not take it lightly. Even if an error message has poor grammar or incorrect spelling, that will reflect on your ability.

7. Speed matters
   All of the above doesn't matter if you don't have the speed! In TopCoder competitions, whether they are on-line or in-person, you have to be fast. This might be obvious, but the faster you are, the more points you get. Also, the faster you complete one problem, the more time you have to solve the other problems. Since there is a limited amount of time for SRMs, if you take 1 hour and 16 minutes to come up with a perfect solution, it won't be worth anything.
   
   In software development, the same holds true at two scales:

   • For the individual developer, the faster you complete one task, the faster you can complete ALL your tasks. More tasks completed means the boss is happier (he gives you more "points").
   • For the company as a whole, the faster the product gets to market, the better. If you trump your competition, you can enjoy larger market share, more sales, etc. More sales means your boss's boss is happier (she gives you and your boss more points.) Getting a robust product faster means the customer is happier so he gives you more points too.
   
   Sometimes, unfortunately, in both TopCoder and software development, even if you're first-to-finish, you don't always succeed. In TopCoder, if someone has more successful challenges than you, they might just edge you out even if you were faster. Similarly, take Netscape as an example; even though they had one of the first widely-available browsers, they were "challenged" by Microsoft and lost.

8. There are people who can help
   During an SRM, if you have a question, the admins are always there to help. (Well, they try to help...) Seriously, though, there is always someone to answer the question. Also, the round tables are a great place to ask questions and make comments, whether they are in reference to a SRM, a write-up, or a general algorithmic question.
   
   In software development, your project manager, senior developer, or other "mentor-type-person" is the person to go to. They're the one who can answer your questions. Similarly, there are literally hundreds of on-line sources to get your questions answered about your development language, compiler, environment, operating system, database, etc .etc. etc.

9. There's money to be made!
   I finally was able to make money coding! After making it to the third round of the 2003 TopCoder Open, I was the proud recipient of a $75 check from TopCoder.
   
   Believe it or not, in the real world, you can be paid to code on a regular basis! Seriously, despite downturns in hiring in software development, the number of unfilled software jobs is still predicted to rise for many years to come. I myself recently got a new job, near my home, doing exactly what I wanted.

10. Don't judge someone by their "color"
    TopCoder can teach us a life lesson. Just because a coder is a "gray" doesn't mean they don't have something to contribute. Conversely, just because a coder is red doesn't mean they have the answer to everything. In a recent round table discussion, a "blue" coder came up with a solution to a research question before a "red" coder did.
    
    Professionally, everyone's ideas are important and should be given a chance, from the newbie HTML coder, to the hot-shot Java guru. You never know from whose brain the "next big thing" will come from. By mentoring and listening to junior developers, you can foster team morale and improve everyone's performance. The hoary software architect can learn new things as they teach, and vice versa.

11. Have fun
    At the top of my Mantra list is now "Have Fun". It's important to remember that! (I know I have a hard time remembering that too.) The instant gratification of software development is probably one of the reasons it is one of the most popular university majors. And admittedly, it is a lot of fun. So go out there, have fun, and write some great code!

Would you like to write a feature?