Diomidis Spinellis gives a list of 10 software tool sins in The Tools at Hand episode of his Tools of the Trade podcast. Here are his points, but turned around. For each sin he lists, I give the opposite as a virtue.
10. Maintain API documentation with the source code.
9. Integrate unit testing in development.
8. Track bugs electronically.
7. Let the compiler do what it can do better than you.
6. Learn how to script your tools to work together.
5. Pay attention to compiler warnings and fix them.
4. Use a version control system.
3. Use tools to find definitions rather than scanning for them.
2. Use a debugger.
1. Use tools that eliminate repetitive manual editing.
I turned the original list around because I believe it’s easier to agree that the things above are good than it is to see that their lack is bad. Some items are opposites, like #5: you either pay attention to warnings or you ignore them. But some are not, like #8. Tracking bugs electronically is a good idea, but I wouldn’t call tracking bugs on paper a “sin.”
Related post: Reducing development friction comments on another podcast from Diomidis Spinellis.
I find that when a program gets to about 5,000 lines, debuggers become useless. They show too much information about things you’re not interested in.
That has not been my experience at all. I’ve found that when programs get too large, the only way I can understand them is to use a debugger to navigate. You should be able to configure your debugger to tell you only what you’re interested in. I’ve had no problem using the Visual Studio debugger on very large programs. Maybe some other debuggers don’t scale as well.
> 8. Track bugs electronically.
I’d say “transparently” so everyone in the team can see them. “Electronically” could mean in your email or with a shared spreadsheet
I think the sin is tracking bugs in your head.
That list is a rehash of parts of The Joel Test: 12 Steps to Better Code, from way back at the turn of the millenium. A very popular form of post over the past dozen years is is the “revised Joel Test.” The Joel Test has even been adopted by Stackoverflow’s jobs board.
Joel was also way ahead of the curve in naming, picking up on the banner-ad- and BuzzFeed-bait titling style of “X things you need to know about Y before Z-ing” and “A ways to be a better B” titling that’s so popular.
+1 on Shawn Corey’s comment. I’d replace it with profiling if you care about efficiency and resource tracking if you use a language that can mess that up. I didn’t even understand point 3. I’ll add a qualified -1 to Joel’s “best tools money can buy” — his company sells version control systems; there’s an advantage on an open-source project to use the best tools everyone can easily get their hands on; but then if you roll that criteria into “best” you’re good to go.
Our project Stan‘s an 11/12 on the Joel Test by the way — the only thing we don’t have is a precise schedule. It’s hard to schedule when your workers are all volunteers and a lot of the code requires research.
I work mainly on CMS development, and I can tell you one thing, Version Control cannot be used in my scenario.
The problem with Version Control is that it expects no modifications, whatsoever, to the filesystem other than through Version Control. This is not the case with the majority of CMS applications, since you will need to install extensions through the backend of that CMS.
So, “Use a Version Control System”, in my opinion, should be something like “Use Version Control whenever possible”
When the web was new, some people argued that web sites couldn’t use version control. I think most people would laugh at that now, but that idea was taken seriously at the time.
When someone says their project shouldn’t use version control, my suspicion is that they should examine how to use version control. Maybe they need to use it differently. It seems that a software project that doesn’t use version control will develop something else that’s effectively a version control system: a way of tracking changes, publishing updates, reproducing previous states, etc.
If a system requires a lot of changes that are not changes to source code, say operating system and file system changes, I’d consider turning it into a source code project by writing scripts to automate the changes and then versioning those scripts.
This is such an interesting discussion; thanks John for spawning it!
Regarding Fadi El-Eter’s comment on the difficulty of applying version control on development with content management systems, I think you’re seeing the problem, because you’re using the version control system at the wrong level of abstraction. You shouldn’t be managing the installation of plugins directly as files under version control. Rather, you should be managing the content management system’s setup using a configuration management system, like Puppet or Chef, and put the configuration management system’s files under version control. You can read more about the use and benefits of configuration management systems in another instalment of the Tools of the Trade column at http://www.spinellis.gr/blog/20120904/