Every now and then I browse over to the popular Coding Horror blog: It’slike turning on an episode of the A-Team andcollapsing into a comfortable couch on a hot summer day, ice cubesclinking around in a sweaty cup of lemonade.
It’s a nice way to zone out, distracting my consciousnessfrom a vexing problem in hopes that a background processrunning in the Brain.ThreadPool completes and returns asolution.
In his post, the Coding Horror author observes that inactual use .NET has evolved into a single language environment,with C# increasingly dominating (though it’s doppelgänger, VB.NET,is only a marginally different variant — C# is theLexus ES300to VB.NET’s Toyota Camry).
Who knew Would you also believe that the Java Virtual Machine can be targeted by languages other thanJava?
He goes on to note his disappointment that the Visual Studio IDEdoesn’t support automatic, continuous compilation for C# projects,which would enable it to quickly highlight egregiousmistakes in his code.
In the comments to his post, I offered up the opinion thatthe reliance upon such a piece of functionality might bedetrimental to the craft of software development.
I encourage you to go a week with minimal automatedcode-correctness checks. When you’ve gotten to the point where yourely upon continuous automated checks (which can miss a tremendousnumber of problems where the code is syntactically and typecorrect, but logically broken), you’ve seriously harmed yourcraftsmanship.
Dennis Forbeson May 15, 2007 07:10 AM
Mr Atwood replied-
Ah yes, that old logical trap. Better tooling makes us weak!It’s a crutch we begin to rely on that cheapens our craft!
This is even debunked all the way back in MythicalMan-Month:
“There is a widespread recognition that debugging is the hardand slow part of system programming, and slow turnaround is thebane of debugging. So the logic of interactive programming seemsinexorable.”
And then, as for the logical fallacy of “easy tools make youweak”:
“So let’s get real. Bad programmers write bad code. Goodprogrammers write good code. RAD lets bad programmers write badcode faster. RAD does NOT cause good programmers to suddenly startwriting bad code.”
This isn’t a zero-sum game; better tools let good programmerswork faster. The bad programmers, well, it doesn’t really matterwhat you give them because the output will be the same:disappointing.
Logical fallacy…zero-sum…a reference tothe Mythical Man-Month…add in “orthogonal“and you’ve got a Score:5 on your hands.
In between appeals to authority — Jeff is a big fan of Code Complete and the MythicalMan-Month, always ready to quote them as the indisputable,final word on all matters relating to software development — Jeffmakes the critical, err, “logical fallacy” of presuming that myquestioning of his automatic compilation dependency (to avoidassigning literal integers to strings, apparently) is an indictmentof all accouterments of software development.
Hardly, Jeff. It might make for a convenient strawman, but it’scertainly not the argument being presented.
I’m not calling for a return to punch-card programming, oreven back to the days when we’d reference our 50lbs of Visual C++reference material to lookup the parameters of an API function.
I even think IntelliSense is quite a great little bit offunctionality.
When you’re randomly typing garbage into your editor,complaining that the continuous invocation of the compilationshortcut is cramping your style (and your fingers), however, you’vedeveloped a serious problem.
Sometimes these features are there to coddle a beginner,carefully keeping them within the painted lines and away from thedangerous electrical sockets along the wall. That would explain whyit was a more important feature in VB.NET than C#…not that VB.NETis any more trivial — it’s just a syntactic variant — but itis the language that beginner programmers are generallyguided into.
And to his last point: My experience has been that thebest developers just naturally start using less and less”helpers”, to the extreme where you have incontestably greatdevelopers like Linus Torvaldsarguing against fundamental helpers like interactivedebuggers.
Many readers may be wondering why thekernel does not have any more advanced debugging features builtinto it. The answer, quite simply, is that Linus does not believein interactive debuggers. He fears that they lead to poor fixes,those which patch up symptoms rather than addressing the real causeof problems. Thus, no built-in debuggers.
I’m certainly nowhere near as extreme as Mr.Torvalds — indeed, apparently Linus has softened his stancesomewhat — but I wouldn’t dare to claim hisexperienced perspective “debunked” because Fred Brooks — operatingin an environment where what is defined as “immediacy” wouldbe glacially slow by today’s standards, and whose metrics hadnothing to do with Edit and Continue or continuous automaticcompilation — can be selectively reinterpreted and appliedagainst a completely different world.
Sorry, Jeff, but I don’t buy the infinite monkeys onan infinite number of keyboards model of software development. Ican only envision tools like continuous compilation and edit andcontinue as the hand-holding of beginners, and the crutch ofhacks.