Of course... that is what the definition of good is!
Also this is true:
Bad architecture has no or detracts from benefits.
I would also say that having an architect is sometimes a bad idea, I
prefer a title of "tech lead". This means that I do code hardest things.
Things that make you more effect
Maybe I'm a lucky one, since I haven't met any real pointy haired bosses.
Maybe I'm just able to speak their language.
I still believe that good architecture has business benefits,
you just have to speak the same language. If you explain the phb in his
language
that you gonna give him the opportu
Maybe I'm a lucky one, since I haven't met any real pointy haired bosses.
Maybe I'm just able to speak their language.
I still believe that good architecture has business benefits,
you just have to speak the same language. If you explain the phb in his
language
that you gonna give him the opportu
Dakota Jack wrote:
> I like the basic premise that usually shortcuts are not efficient.
> That is also what I have found.
>
> Jack
>
>
No argument there, except that my basic premise I believe still applies
as well... The business has to understand and agree with that basic
premise as well as IT
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.
> 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 rea
I like the basic premise that usually shortcuts are not efficient.
That is also what I have found.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
-
To unsubscribe, e-mail: [EMA
> 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 rea
I don't think anyone would argue with your basic premise Antonio.
However, I think Andrew is correct... theory and reality rarely meet in
the real world.
Where I work, we currently have a lot of high-level architects that are
trying to implement enterprise-wide solutions to common problems, try
> Lets face it, those of us who actually try to do things right will just
> get labelled as 'perfectionists' and not 'people who get things done',
> and the time we have to spend wading through the code the got-doners
> left so we can add feature Y makes us look like a hopeless bottleneck
> when co
I dunno mate. The usual technique in the industry would seem to be some
variant of the following:
Write junk
Go home on time (actually get to see family occasionally!)
Leave for better job letting someone else cleanup mess
Repeat as necessary
(Health department warning: If repeated excessively ca
I'd like to share with you a small experience with bad programming
practices I had just yesterday.
I made a Struts-based application a while ago, when my experience with
J2EE application was at its beginning. I wrote a "Business Delegate" (the
quotes are intentional) that had an HttpServletRequest
12 matches
Mail list logo
