Good pain (was Re^2: Nice clothes ...)

I've always enjoyed reading the various Paul Graham articles pointed at by monks, and this one is no exception.

I disagree with one part of it though:

Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.

While I understand his point, I think it all comes down to how you react to these minor torments. If stepping on a nail just causes you to jump around going 'ow' a lot, no great gain. If it causes you to design a new nail, or a new shoe, that'd be quite another matter.

Similarly, a fickle client gains you nothing if you just throw away and rewrite (or start to pile hack upon hack); however if it causes you to redesign your application to make it easier to respond to changing requirements that'd be a good thing.

In software, I find that simplicity and elegance often reflect good prediction - you've correctly guessed what types of flexibility will be called for in the future, and provided for them, so that the software has not degenerated into a mess of hacks as requirements have changed (as they always do).

Hugo

Comment on Good pain (was Re^2: Nice clothes ...)

Replies are listed 'Best First'.
Re: Good pain (was Re^2: Nice clothes ...) by dragonchild (Archbishop) on Aug 08, 2004 at 19:34 UTC
I agree with your sentiment, but it doesn't play out in the real world the way you hope. An analogy would be that a client goes to the best sprinter in the world and says "I need you to run the 100m race tomorrow." Not a problem, right? Well, that night, the client calls the sprinter and starts to describe the outfit. Ok, still not a problem. The chicken outfit isn't aerodynamic, but he can still run the 100m race. Then, that morning, the client says "I need you to run it in world-record time." A real world analogy is what's going on at work right now. The main application is suffering from a very poor design, continuously shifting requirements, and lots of developer turnover. This has caused it to place inordinate load upon the database server. We hadn't been able to upgrade it because the parts were unavailable. (Yes, that does happen, even to Sun servers!) So, performance degraded exponentially with the number of new users, and we've been adding 20 employees a month. So, what worked for 100 employees doesn't when you have 200+. The VP says "I need the performance improved." We tell him your choices are: Buy more servers Rewrite the app so that it doesn't place that inordinate load His response was "I don't like those choices. Give me another one."¹ Or, how about the time we moved into a second location and had problems with the bandwidth between the buildings. That was impacting the users. So, he calls us into his office and says "What can we do to solve this, but don't suggest adding bandwidth or any new development." It's nice when you can predict the future "needs" of your clients, but if you can do that on a regular basis, you're either in the wrong business or you ended up with a bloated mess called Windows. We wanted to say something along the lines of "Sure. Give me a second to reach up my ass for that!", but then we wouldn't be able to pay our mortgages. :-) ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^2: Good pain (was Re^2: Nice clothes ...) by tadamec (Beadle) on Aug 11, 2004 at 09:42 UTC
You know, I think we worked for the same guy. This is a true story, and this type of situation happened on an almost daily basis for the year I worked there. I'll keep the company out of it, but the application we were maintaining kept statistical data on cellular phone calls. We were inserting on average 100,000 rows of data per hour and summarizing them into some 50 or 60 reports generating an additional couple of million rows per hour. All of the individual detail records needed to be available, as well as any range of data that management asked for. And the raw data files had to be kept on line. I come in one Tuesday morning to find a note from my boss: "Come see me right away about the database migration this afternoon." Database migration? I haven't heard anything about a database migration. We had just finished migrating our MySQL database to a Sun E-4500 server that had been maxxed out in both processors and bandwidth. We had also moved from a couple of JBOD arrays to a nice EMC Clarrion array with around 2TB of space. We also had a processing teir (an E3500) that did a bunch of other work on the files, moving some of the really nasty data transformations off of the database server so it was snappier for queries. "Tim," he said. "I promised this other department that they could have the 4500 because we didn't need the power." I gasped, noticing that "top" routinely reported utilization at .9 no matter what time of the day we ran it. "Did we get the E10K," I asked, somehow maintaining my composure. "No, I've got an Ultra-60 that we can migrate to. It's dual processor; should be pleanty of power. Oh, and the reports are running slowly. It's taking 20 minutes after the top of the hour before the engineers can look at their numbers. We need them available instantly." "Not possible," I said. I knew that wouldn't matter, but I felt a moral obligation to say it. "You've just removed 90% of the processing power from the database server and you want me to make the application run faster?" His reply: "That's what I pay you for. I tell you what to do, you do it. If it's not possible, you need to find a way to make it possible." I went to my desk, fired off a letter to his boss explaining the situation. I then went into his office and said: "Hey, I've solved my problem!" "Good deal! I knew you'd come up with a solution." "Yep," I countered, heaving a sigh of relief. "I quit. It's your problem now."	[reply]