I find myself trying more and more to suppress my own OCD tendencies of perfectionism..

Hard to find the balance, but I really think this made a good point and more clear to me actually.

Problem is, sometimes people write the prototype then go into ’stovepipe/BBoM/Architectural Astronaut mode’.

Also, this: http://www.joelonsoftware.com/articles/fog0000000069.html

“The only way out this trap is acknowledging that simpler is harder”. I guess the key point is ABSTRACTION. If you get the abstraction / architecture right, there goes most of your problem. And yes, it is hard.

You seem to present an over-generalized view of what “the corporate world” means. Where I work we do have pretty high standards for code quality, and care a *lot* about how maintainable a product is.

Also, like Leonardo, I do believe it’d be feasible to propose this in cases where we have to understand the problem domain better. It would need discussion and analysis to get accepted, of course.

Tight schedules and short budgets do happen occasionally too, and these will certainly limit what’s feasible. I don’t think that’s specific to that “corporate world”, though. Schedules and budget is part of our society, and we have to learn to deal with them in a positive way.

Leonardo,

Yes, indeed if all one can do is writing ugly code, writing more often, publishing, contributing, and learning from mistakes and external advices are good ways to move forward. Reading and comprehending good code is also a good way to improve one’s practice.

The only way out this trap is acknowledging that simpler is harder, is to detach yourself from your code and not be ashamed of publishing ugly code (or you won’t publish none). One probably has to learn this the hard way though

> Can you convince your boss that you should work one or two months in a problem and then throw away the result of your labour?

Well I can and you too should work for enlightened companies!

I agree that it’s a very good practice and will doubtlessly make your final software better designed. But that’s not what the corporate world wants. They only want something that works good enough (with surprisingly low criteria for “good enough”) so that they can sell it. They don’t even care if the codebase is maintainable. They’ll just keep throwing more developers at it if it isn’t.

Software companies care a bit about good design, and try to get it right. But only to the extent that it doesn’t get in the way of their tight schedule and short budget.

I don’t recall this being a documented part of any of the agile processes I’ve read about. It’s slightly different to embrace change, which is indeed advocated by them, and to design a system with the goal of learning about the problems at hand.

I may be wrong, of course. Do you have any pointers to documentation of the common agile methods which indicate something similar?

In the team I’m part of, for instance, we have pretty much trashed and rebuilt a system once, but this wasn’t planned and it took some time to understand that it was an issue, and to accept that it was needed.

Here are 2 nice quote from it:
=====
Someone once asked Somerset Maugham if he wrote on a
schedule or only when struck by inspiration.
“I write only when inspiration strikes,” he replied.
Fortunately it strikes every morning at nine o’clock sharp.”
That’s a pro. (p64)
=====
Why have I stressed professionalism so heavily in
the preceding chapters? Because the most important
thing about art is to work. Nothing else matters except
sitting down everyday and trying. Why is this so
important? Because … [when we do that] … something
mysterious starts to happen. … heaven comes to our
aid. [Professionalism or Artist's Code or
Warrior's Way is] an attitude of egolessness and
service. (p108)
=====

The advice seems to be more important for those who are still in the waterfall age.