Who's the greatest software developer in the world? It's certainly not me and I would mistrust the judgment of anyone who self-identified as such. How would we identify said greatest developer? Is it someone who writes the purest code? Is it the developer produces the lowest bug/code point ratio? Should development speed count? How about the sheer ability to Get Things Done? I'd give a long, hard look at developers who fall into the latter category. Too frequently I hear "purists" talk about abstract ideals which, when the rubber meets the road, fail to have much traction. Regrettably, I've fallen into the "purist" trap on more than one occassion and have had to eat my words. Purity is in the eyes of the beholder.
Still, being able to Get Things Done is pretty powerful. Many Perl programmers follow this (and we often brag about it.) We sometimes talk about the importance of using strict, eschewing globals, and avoiding code bloat, but we also enjoin programmers to use CGI.pm, a module that is powerful and gets the job done despite violating those "pure" concepts.
We also get into flame wars about whether or not we should use ref $proto || $proto in our constructors. Sometimes it's a good idea; sometimes it's a bad idea. However, it's almost always a bad idea to argue this point when the deadline is looming and we're not sure we'll make it. When that happens we stop arguing, ignore the offending line and our product ships with contructors that blur the distinction between classes and instances of said classes and we squirm at the idea of people seeing our bad code. Perhaps we squirm at this idea more than the idea of our writing bad code. But how much does this matter in the real world?
I've worked for more than one small company that had little project management, no programmer tests, the programmers doubled as QA people and yet the companies still made money. I heard programmers grumble about how they wished they could work for a "real company," despite the fact that they had a paycheck, a retirement plan, a mortgage and all of those other things they would get if they worked for a "real company."
Curiously, I've worked for "real companies," too. One in particular stands out in my mind. This company had lots of project management and QA departments (but still no programmer tests.) They built bigger projects that failed spectacularly and sucked up lots of money, but this "real" company could afford the losses.
I have friends who work at large, "real" companies that have become household names and they bemoan the poor software and security practices of their companies. This only serves to make me wonder which is the greatest software development company in the world. Though I don't think we can ever identify "greatest," I do think it's safe to say that it's a company that Gets Things Done. Though it's heresy to many, Microsoft falls in that category.
When I worked for Onsite! Technology, we Got Things Done. At our height, we had four software developers, a system administrator, two graphic designers, the owner, a VP/Project Director and an office manager (the latter two double as our QA department.) We kept churning out products, we made good money and had lavish Christmas parties, a game room and were one big happy family. I loved those guys and life was good. What finally sunk us was the Big Project. The owner had a brilliant idea that had tremendous industry backing and to this day I am firmly convinced that we would have gotten very, very rich. Except we had no money for this project. It's tough to be rich when you're poor. Putting development time into this idea meant sacrificing some of our paying projects and we had too much work to do and, since this was shortly after the dot-com collapse, no investors would take a chance. Too much work for too little money destroyed the company, left many bad feelings and the lawsuits are still ongoing.
I have turned down more than one job because I felt the project management was lacking. Now I wonder if I was too hasty. While solid project management is certainly critical for information management as a company grows, if the projects are small, everyone tends to know what needs to be done. At Onsite!, if I didn't understand what a particular screen needed to do, I just walked into the owners office and asked him. It was that simple. Even our Big Project was working out fine and we produced some great code because it had been broken into smaller, manageable parts (lack of money, of course, being a separate issue.)
The point, I suppose, is that "purity" of ideas is a nice thought, but it's not always the most practical thought. I've code still running in production that, while it's not something I would submit as a code sample, is still chugging along quite fine. There are plenty of projects churning out sloppy code, led by micro-managing dictators that are still Getting Things Done. While we can find plenty of awful code that legitimately should never get into production, we also find beautiful code that costs too much to produce. While I often wonder how best to determine the balancing point, I also recognize that this is how things are and I shouldn't feel bad if I don't produce the best code on a given day because I might just be producing the best code that can meet the deadline.
Re:Stupid things
zatoichi on 2004-07-06T02:43:17
Hoo boy! I do not subscribe to that as I have done things that "work" but even I admit that the solution was "stupid".Re:Stupid things
petdance on 2004-07-06T03:05:28
But what is "stupid"? I think programmers have an all-too-common tendency to worry about the "right" way of doing things from a programming point of view, and ignoring the business reasons, whatever "business" that may be.Re:Stupid things
Ovid on 2004-07-06T14:11:41
Curiously, we recently had an applicant who seemed really solid, good skills, nice background, but kept talking about their desire to write perfect code. There was a great feeling of unease about whether or not this individual would be sometimes be willing to write code that was less than perfect in order to meet deadlines or odd requirements (we never found out. He doesn't work for us.)
By the way, will you be at OSCON this year?
Re:Stupid things
petdance on 2004-07-06T14:46:49
Yessir.Re:Stupid things
Ovid on 2004-07-06T15:45:45
D'oh! And I had read that, too
... See you there.
Re:Stupid things
jdavidb on 2004-07-13T14:24:12
As long as "it works" means "it passes the extensive automated test suite."
Re:Understanding the problem
Aristotle on 2004-07-06T17:12:41
This is exactly how I feel.
Code is always a trade-off. It always caters to some cases better than to others, because there is never any single way to do things that would always be best. Of course, I'm not saying anything new — this is why Extreme Programming proposes what it proposes, and why it embraces constant refactoring as a way of life for a project.
What is important, is to be aware of the trade-offs. That requires a solid understanding of the problem first; it's okay to parse HTML with simplistic regexen, so long as you know exactly how your input data is structured, and sometimes even if you don't, as long as you make sure that it's not impossible to come back to this bit of code later and fix it up.
“If it's stupid and it works, it's not stupid” actually sums this up nicely: the catch is, do you know it works? If so, well then of course, it's not stupid.
