I think we're pretty much done, I do beleive that a configuration should
reflect the environment it runs in, but I think our opinions differ when
it comes to allowing developers to dictate behavioural changes between
environments and shipping code which is never executed.
Brian Pontarelli wrote:
I think we both agree that configuration is best. In fact I think you
even support environment awareness in configuration system. So, from
that perspective we are solid. The rest is just debating personal style
and developer freedom. I will answer a few things below, but I think we
can close out this thread or take it off-list.
The key thing here is that S2 *suggests* it, it doesn't impose it. My
point is that it is fine to suggest it something that the user can
alter, but it is bad to do something which alters program behaviour
without the environment managers involvement as would be the case with
a conditional branch dependant on it's environment. I would also ask
the question of "If a developer has seen the framework exihbit a
behaviour, are they really a bad citizen for making use of it?".
Suggestions aside, S2 still doesn't make this easy. It needs environment
awareness and it should probably default a ton of stuff when in
production mode. This one being the top on the list.
Being not easy and being not possible are worlds apart. My view is that
it doesn't have to be easy, but it should be possible and developers
should not dictate behvioural changes when an app is moved between
environments.
I'm also not a fan of just accepting something as good if it's a
de-facto standard because I know from experience that not all
decisions which make it into the wild are teh right thing to do. Would
S1 have been released if WebWork had already been floating around?,
Would the Java UI Event model in 1.0 ever had seen the light of day if
someone had already started work on what became the 1.1 model?, and
you just need to look at the history of EJBs to see things which were
de-facto standards which have now been "retired" (Home/Remote
interfaces, Message beans that could only get messages from JMS).
Not accepting crap is one thing. Not accepting something that is outside
our comfort zone is something else entirely.
Very true, but some things are just crap that looks OK in the right
light whether they're inside our outside our comfort zone.
To me the big switch idea is like hard wiring your headlights and a
speed limiter into your windscreen wipers. Whilst it might seem a good
idea, there are situations when you'll just want the wipers on or off.
Haha. Not even sure that's similar enough to the cases I mentioned to
make sense. Humorous though.
Glad you appreciate the humour :), the point is that some decisions can
look good from a certain standpoint, but when the end result goes into
use it prooves to cause some unexpected problems.
You may not be happy about it, but a production issue may neccessitate
it. My previous message had a real world example of where a database
was moved to a smaller system because the performance of many apps was
poor due to the total load on the database cluster.
Orbitz was slightly different. No one made environment changes without
consulting a developer. We had it happen a few times and it didn't go
well because the complexity was too high. It always looked like an
acceptable change, but the developers who wrote the code always knew
something that others didn't. That's why nearly all of the developers
wore pagers and everything was setup to allow developers to help make
decisions. Now, that's just Orbitz and I'm certain there are different
environments that this would be okay. But I figure call the developer
first and double check to see if any flags go up.
It's an interesting way to do things, but relies on the developers of an
application staying with the company (and not being on vacation),
remembering all of the things that they've done, and creates a single
point of weakness - the developer.
In the environments I've worked in developers are/were moved between
projects and there was always an element of churn (i.e. people leaving
and joining), so after six months the developer may have either lost
much of the knowlege relating to the app due to having a new focus, or
may simply be not around.
Within many of the companies I've had exposure to that are based in the
financial sector there is a requirement to have a single two week block
of vacation in which you are considered uncontactable. This ensures that
no matter what happens to the employee the company can still function,
because even though we don't like the idea, people do get hit by busses.
In the UK and the US almost all major banks aim to be able to fail
over to a DR site within 2 hours for all critical applications, if you
add in the requirement for a developer to make a new release for any
configuration change that needs to be made you're wasting valuable time.
Yeah, we didn't do releases to change configuration or the environment.
It took days to do a release. We just patched things. I know people are
feeling a little sick at the thought of ad hoc patching, but it worked
for our situation.
Ad hoc patching isn't nice, but sometimes it's a neccessity.
My issue is when you need a developer involved in every change the
number of people involved in any change increases and therefore so does
the time needed to make the change, and when time is money the number of
people needed to make a change tends to get "optimized".
But if you dictate behaviour why should your choice change just
because the app has changed environment?, if it's a useful feature for
you in dev it will most likley be a useful feature to a techie trying
to resolve in issue in support, so it should be a configurable switch,
not a cast-iron decision that allows you to access features which help
you debug the program in dev but provent the techie checking for the
source of a problem in production or test .
Might be useful, but in some cases if you turn on cache checking it will
crush the entire system. Again, I'm just advocating being pragmatic and
protecting the system. However, most cases aren't like Obritz and I
could definitely see that leaving cache checking turned on won't impact
things too much. But, I'm sorta stuck now and so I do a lot of my work
thinking about massive scale up front.
I can see where you're coming from, but I'm fimly in the camp that if
it's useful in dev it may well be useful to a techie.
If a problem arises on a customer site I'd far prefer to be able to be
able to ask a techie to turn on cache checking (or any other dev
feature) by setting an option, warn them of the system impact, and get
the results after a short run, as opposed to having to send a developer
on site to check and probe the customers environment. If nothing else it
means that we can quickly and easily run our tests in their environment
as opposed to hoping that we can accurately model their live environment
in order to replicate problems.
Al.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
