|
|
Re: Is it ever too early to optimize?
|
Posted: Nov 11, 2003 2:27 PM
|
|
To me there is a huge difference between premature optimization and writing sloppy code. People seem to use the 'don't prematurely optimize' mantra as an excuse to write crap software. There is some middle ground that people should strive for but don't. This conversation with Scott Meyers says it best, I think http://www.artima.com/intv/const3.html. I think a big part of that is the advances in hardware as you say. If you have gigs of disk space and a gig or more of memory and you have to get something working, then you do what you can to get what the customer wants in the shortest amount of time and that, unfortunately, is where most applications I've seen appear to stop. Even if the developers planned to go back and optimize, they don't. There's always that next project that has to be done. No time to go back and work on code that isn't broken. That's crazy, right?
I also think a big part of this trend is the adoption of agile methods, as well. I think a lot of their tenets have been misread and poorly adopted, kind of like Bruce Lee's 'Using No Way as Way, Having No Limitation as Limitation.' The uninformed look at this and say 'hey, I can do what I want and that's a valid way' without taking into account the context of the saying and the kind of person Bruce was and the kind of life he led and the amount of work he had to do to become the man he was.
It's like the frequently quoted musician's adage that you shouldn't break the rules until you know what they all are. I have yet to work on a project that was well planned and designed that has been a problem. All of these projects have gone well. They may have been a bit late, or not had all the features users wanted, but they were solid pieces of software and adding things in later was never an issue because they were designed that way. I can't say the same of projects that used more 'agile' methods. Most of them had no planning, poor design, one team didn't know what another was doing so the interaction of various pieces was unpredictable, etc.
From what I've seen most people aren't good enough programmers to use agile methods because they lack the discipline to do it correctly. I think I can include myself in that group. They don't care about talking to customers, so they don't. The parts of the agile manifesto about striving for technical elegance, excellence and good design seem to take a back seat to getting something 'working' out the door, when they should at least have equal footing. Most of the developers I work with don't want to ever talk to a customer, so I don't figure how they think Agile methods will ever work for them. We don't get customer feedback, anyway. We're a commercial software company. We would spend all of our time talking to customers and doing nothing else with the amount of customers we have. Most people I know AREN'T SELF ORGANIZING, so there goes the best source of architectures, requirements and designs. Most programmers I know won't bother tuning and adjusting their behavior to become more effective because they think they're good enough.
Heck, if I want to take agile methods to an extreme, for every new project I'm going to open up my Python interpreter, type 'print "New Project Version .01" and call it a day. That's the simplest thing that works, right? I just put in a full day! Woohoo! Working prototype! Never mind that the final project won't be in Python, it has a tremendously complex GUI and uses a combination of database calls and web services. That's fluff I can address later. Besides, the requirements are going to change anyway (I love this, because it lets people get out of writing requirements in the first place and this has been the cause of problems beyond counting), so why bother writing them?
Lately this has become a particular sore spot for me because
A) I seem to spend a lot of time cleaning up other people's messes because they write inherently inefficient code that worked fine in our tests, but once it gets into a real world BIG implementation, it runs like a three legged dog. Actually, I should probably take that back because it is terribly insulting to three legged dogs.
B) Our current management seems to think that getting the thing out there as quick as possible, no matter how it is designed and written is fine. That is, until we get hammered with bugs and then we're spending inordinate amounts of time fixing bugs and we get lambasted and reprimaned for releaseing such a buggy product. And then all the "I told you so's" in the world don't make a difference. No matter how many times you try to warn these people about the inherent problems, they don't seem to care until it's too late. If they let us do our jobs in the first place and design the software the way it should be designed, it might take longer but the savings in the long run would be huge. Alas, that takes forethought, which I'll address, well, now.
At the end of this log you say "It's all a matter of balance and forethought." From what I've seen, there is a severe lack of both in the world. Especially forethought. I've seen little evidence of thinking, period, lately. It's a constant point of tension between me and the people I work for.
Like I said, this is a real sore spot for me. I could probably go on for days about this, but I have to get home and get me some dinner.
|
|
Previous Topic
