Know Your Resources
So how do you help the good programmers grow into superior programmers that can write such code? Early on I somehow stumbled upon something that saved my career many times. I realized that I couldn't possibly know everything. Instead, I realized that a good programmer knows where to quickly find the answers.Consider the earlier threading example. I mentioned it's on an ASP.NET platform. Off the top of my head, from experience, I know there's a class that allows file locking for read and writes. I can't remember the exact name of the class, but I know that it involves locking and reads and writes. And I know where the standard docs are: the MSDN online documentation or, better yet, the local copy that ships with Visual Studio, the Combined Help Collection. Or, better still, if I remember when I wrote the code before, I could just look at how I did it before. And that means I can immediately locate the name of the class when I need it. Of course, some really confident programmers want to "roll their own" and build their own locking mechanism, for example, and skip the built-in classes. This could happen for a couple of different reasons. First, the programmers might not even know that there's an alternative to rolling their own. How could they know that there's a handy class built right into the .NET framework that handles the read and write locks? The key is using what I learned so long ago, and knowing the resources and taking a few moments to look through them before rolling your own solution. And that's where you, the manager, can help: You can require that your programmers go through the online docs and find whether the solution already exists. But the other reason a programmer might want to roll his or her own is because he or she might think the pre-built one isn't good enough. Now remember, I'm not talking about entire systems here that are already built. I'm talking about small, individual functions and classes, the nuts and bolts of your system, such as the file locking mechanism. Remember, programmers like to build things. It's their nature. And they feel especially good if they can build something that was better than the previous one. But also remember: The class in this case is already built, and takes just a couple of lines of code to use. And it's already been through testing at Microsoft and has been used by thousands of other programmers successfully. You know it works. Also, programmers have a tendency (myself included) to want to add all sorts of extra features to really make something cool. For example, a file locking mechanism would be even more useful if it included built-in file caching and a queue to manage the locks, and went far and beyond the little one in the library. But that's overkill. And the last thing you want is for your programmers to spend two weeks, a week or two days writing code when all they need to do is write the one or two lines to make use of the class Microsoft gave us (or whoever built the library you're using for your particular platform). Besides, remember that even though the programmer might be able to roll out his or her own version in a day, your testers will have to now test that code in addition, and what was a day of work could turn into a week or two weeks. Compare that with using one or two lines of code that call a pre-existing, tested class. Which, then, I ask is better? Which is the right way to do it? Of course, there may be times where the built-in class doesn't do everything you need. In that case, you need to carefully weigh your options and tradeoffs. Is there a way to make use of the class, just without all the extra features you were hoping for? Or is there a way to build a new class that expands on the existing class? (That's usually your best option.) Only if not should you consider having your team writing their own class. But you'll want to make sure you've exhausted your options before going that route. The last thing you want is to find out six months down the road that the thousand lines of code somebody wrote are barely functioning right, and it turns out there was a pre-existing class that did exactly what you needed and would have required three lines of code on the programmer's part. Conclusion The moral here, then, is to make sure your programmers are familiar with the information resources, especially the online documents, as well as any existing libraries and frameworks they might have access to that have been tested many times over. Then you need to make sure that they're not rolling their own classes and components when one already exists that does the job. Finally, they need to be aware of the real issues that come up in a multiuser, high-performance system such as a Web server handling thousands or even millions of sessions a day. Jeff Cogswell is the author of Designing Highly Useable Software. Currently Jeff is a senior editor with Ziff Davis Enterprise. Prior to joining Ziff, he spent about 15 years as a software engineer, working on Windows and Unix systems, mastering C++, PHP and ASP.NET development. He has written over a dozen books.
Often programmers would come to me for help. And more times than not, I'd say, "Give me 10 minutes and I'll have the answer." Then I'd go back to my cube, quickly look up the answer, and then return. What was I doing? I was going through the same references (Web sites, books, online help) that I'd been through so many times before and finding the answer quickly. So rather than just give up and call someone else for help, I would find the answer myself. Of course, each time I learned the answer, I'd try to remember it, at least in general, so that if it came up again I would either know it or find the answer even more quickly.