|
Fast or Good?
Write code fast or write it to last. Your choice boils down to the trade-offs and compromises inherent in computing
by Peter Varhol
February 14, 2006
A couple of things I've read recently have made me look once again at the whole problem of advances in software development and productivity. The first was the serialization of a talk given by Charles Petzold to the New York City .Net User's Group titled, "Does Visual Studio Rot the Mind?" The second was a blog post written by Joel Spolsky titled, "The Perils of JavaSchools" (see Resources for links to both sites).
Petzold might be considered to be the dean of Windows programming authors, while Spolsky's Joel on Software site is one of the most coherent and widely-read blogs on software development and the software business around. That both focus on development using Microsoft languages and tools is mostly irrelevant, and Petzhold's comments on Visual Studio could be applied to recent advances for any IDE.
Let's start with Spolsky. He notes that a number of universities offering computer science degrees have based their curricula more or less exclusively on Java, which might seem to be a good thing to the readers of these pages. However, Spolsky notes that Java is simply too easy a language on which to base a foundation for learning computer science. He may have a point, in that programming in Java is not a good way of learning about how executing code interacts with memory, for example, since the JVM largely abstracts memory utilization from the coder.
As an employer (he is founder and head of Fog Creek Software), Spolsky also claims that Java is simply too easy to enable him to distinguish between average programmers and great ones. I don't think that he has anything against managed languages in general, but strongly makes the point that any computer science education without working with pointers and lambda calculus is inadequate. A fundamental understanding of how computers really work may not be possible with Java.
Going with No Flow
Petzold describes how Visual Studio tools make it possible to write fast code, but not necessarily good code. Visual Studio (and to be fair, other IDEs, including Java IDEs) treat applications not as one continuous flow of logic, but rather as a set of code snippets associated with user-interface elements. There can be no sense of the flow of execution because too much of the code has been generated rather than written.
Likewise, generated code can be problematic. I don't think he's necessarily against it (although he does seem to prefer writing his own), but he does note that there is no chance to inspect or change it. Visual Studio also makes assumptions about what files and libraries need to be included in a project, and it often adds things that are simply not needed. In addition to code bloat, this characteristic makes it hard to maintain the application over time, as future programmers assume that files were added for specific reasons.
I often wrestle between the need to be productive and the need to understand what is happening in an application in a deep sense. The business developer within me knows that applications have to be completed and put into productive use more quickly than ever. And as those applications get more complex, the tools have to provide a higher level of productivity aids to meet rapidly changing business needs.
From this perspective, the modern IDE is great. We don't spend a lot of time writing code that the computer or operating system, but not the application, requires. The "software backlog" of up to three years that was the bane of the 1980s and 1990s has largely vanished, thanks to the improved productivity of developers using modern tools. While it still takes time to write software, there are many possible ways of doing it so that tight schedules can be met.
Back to top
|