I don't disagree with anything you've said Leon, but I think your leaving out one factor: it is not unusual for the business to impose a deadline on you that simply makes it impossible to not work suboptimally. Or they impose a budget that has the same effect, or some combination of the two.

I know full well I am not in an unusual environment in this regard, although it is quite possible you yourself are in one of the good ones where the business understands everything you said and works WITH IT, as it should be. That isn't the case everywhere though.

There are plenty of places where the business doesn't understand that proper architecture is in their own best interests, they simply want a solution by the end of the week and they don't care what shortcuts you have to take to achieve that goal. You can fight it all you like, but in the end the business makes the decisions.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

Leon Rosenberg wrote:

Frank W. Zammetti wrote:
At the end of the day, my job isn't to design architecturally perfect solutions, it's to implement solutions that support the business. I make a huge effort to achieve BOTH those goals, as we all should, but that's not my primary focus. That's the reality.


No ist not. The reality is, that the perfect architecturally design is the solution, that supports the business best.

An architecture which has paradigms incompatible with the actual use cases and following some theoretical "pathes" instead (like using design patterns by hook or by crook, without checking if they are needed or even useful in the special case) is crap.

The real problem, that most "so-called-architects" have, is _UNDERSTANDING_ the business needs. If we, architects and developers, would
actually _LISTEN_ to the business people, we would achieve both goals easily.


In fact this is something propagated by XP, which brings me to the original
post by Antonio:
- Ever heard about refactoring?


Personally I think that "thinking it will be useful in the future" and
wasting time for it, is the greater sin. This is not an encouragement to
write bad code, but to write clean, classy code, where you know, for every
line, why you did it this way or another. The time wasted for implementing things, which might be useful in the future, should
be better invested in documentation, it will help you more in 6 month,
because things you need in 6 month are never equal to things, you thought
you would need in 6 month.



Regards Leon









--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to