> This post is directed to all application architects and
> team leads.
> My company is currently retooling itself for web
> application development, and as most of you have
> experienced with this type of transition, a lot of work
> must be done up front to design/build/test your
> architecture, create a programming model for your
> developers, create and execute a strict adherence to
> methodology, doentation, processes, etc. All of you
> know the drill.
> The struggle i am having with my team is trying to
> determine where the fine line is between exercising
> extreme control over development and allowing them to
> define the process. The trade-off here is obvious; more
> control = more design and more development but more easily
> maintained code VS less control = Fast development and
> design and less maintainable code. A happy medium is what
> we continually strive for to achieve best results,
> however, i have one particular example that i can use to
> illstrate my issue more clearly.
> The current project is designed for an intranet corporate
> accounting information system.
> We are toying with the idea of managing how a development
> team (now 6 but will be more than 10 soon) uses the
> session object. We all know that memory usage on a Web
> Server is a sensitive topic, and that allowing developers
> to use the Session object carelessly can lead to disaster.
> Blind trust works well in a small team, but when you have
> a larger team that is often disconnected geographically or
> culturally, you can't always rely on the best intentions
> of developers. After all, it is not their responsibility
> to manage Web Server resources; as this often squarely
> lands on the shoulders of the lead architect or the
> operational architect.
> So, how do you employ a measure of control that empowers
> the architect to continually keep tabs on how the session
> object is used? (million dollar question) Here are some
> possible answers to which i would appreciate any replies.
> 1. Keep a word doent to capture all session variables.
> One person is responsible for maintaining this doent.
> This will later be used to derive a baseline for memory
> usage during load testing.
> 2. Add all session variables to web.config or a different
> XML file, to be loaded into application memory, which in
> effect becomes a form of doentation as well. A wrapper
> is used to manipulate all Session requests. This will
> ensure that developers cannot use session variables unless
> they have been included in the xml file. The wrapper is
> also useful if i want to change the implementation of the
> session state management (don't have to recompile all code
> currently referencing the session object directly).
> 3. Trust the developers to use Session appropriately and
> monitor this periodically with code reviews. Certainly the
> fastest and easiest method, but i wouldn't want to find a
> problem 2 days prior to a major deadline.
> Maybe you have more creative ideas of tackling this
> specific problem or the general question as a whole.
> Either way i would love to read your ideas on the matter.
> Thanks in advance,