Things only learned the ``hard way''
I will attempt to summarize what I've learned in the process of writing and rewriting Vincent. I think these are lessons all students of computing would do well to learn. Unfortunately, some of these lessons are only meaningful when learned ``the hard way.'' This document does nothing to explain the hours, the all-nighters, the pain of dealing with users---students, graduate teaching assistants, faculty who think you're their 24-hour support hotline---everything that comes with writing software. In the end, it probably isn't worth it, but I don't expect this document will drive any student of computing to basket weaving.
- Learn to say ``no.''
- Never write software in an academic environment as a student. The lines are unclear (the people using your software also give you a grade, or decide whether or not you have a job).
- Design first, code later.
- It's about the data, stupid. Start with your data. Understand your data.
- It's about the users, stupid. Have clear use-cases up front. Your data needs, squeaky clean in theory, will be dirtied by practice. Understand how your program will be used, and re-examine your data in light of these real-world facts.
- Cute, insulting error messages are not cute, but are insulting.
- Performance is important in any application. While you might like to ``do it right,'' ``doing it so it works'' is important, too. This can impact your data model in ways you might not expect. Plan for it.
- Keep it simple. Start with the smallest subset of functionality possible, and implement it. If you can't write a small, extensible framework, you aren't going to be able to write a big, extensible framework. Rewriting a small program after making implementation and design mistakes takes less time than rewriting a big one.
- Comment, comment, comment. You should be able to remove all the code from your files and understand what is going on without the code. It does not matter if you use JavaDoc, PerlDoc, or anything else---your comments should be regular in structure and consistent in application.
- Avoid languages that are not lexically scoped. Perl, for example.
- Avoid languages that look like spaghetti. Perl, for example.
- You can't write good software in a language you don't know, unless you're really good.
- Know what you are expected to provide before beginning; make sure all parties are in agreement. Get things in writing if you are in doubt.
- Don't take on large projects on your own; know when to get help, or bail out. There is no honor in being a stressed-out, tired wreck.
- Know your priorities. It is easy to code to escape, if you are capable of coding. You feel productive, but you're not doing what you should be doing. You're in school to go to school, not write software. Go get a job if you want to write software.
Postscript: Mistakes of Vincent's Future
While I've talked about lessons learned, implying mistakes made in the past, the question is whether my current plan to rewrite or reorganize Vincent is a wise one. Currently, Vincent works. This is important---working software is a good thing. New software has bugs, and tends not to work. A rewrite of Vincent might just add another bullet point to my list of lessons learned:
- Don't throw out good code. If it works and is ugly, it probably got that way for a reason. Bug fixes, tweaks, and other little bits work their way into code over time. Countless hours of thought and process are represented in mature code. Better to re-visit, re-document, and re-engineer what needs to be fixed than rewrite from scratch.
|