Add a comment


Re: Re-evaluating software architecture

The idea that a developer does a "bit of programme management" might come as a blow to the egos of CTOs with decades of experience who are in charge of millions of pounds of IT spend :P

The example of distributed transactions is a good one: were the failure modes specified in the requirements? Did anyone even notice if they weren't? Will you really be able to unwind an incorrect decision when you (later) discover what your real need is? Of course, the answer depends on the context. Some teams will sail through such a change, others will implement a point solution, others will say the problem can't be fixed, some will have guessed right, some will have planned right, some won't even know what's going on, etc. If the decision is wrong, some companies won't even notice, others will see their customer base evaporate after an embarrassing failure.

So, as you might have guessed, the answer to your questions is, "it depends". One team I've worked with didn't even care about a single transaction. Others could tell me more about XA than I cared to know. It's easy to say that the former team should know more, but since their day rate was less than 20% of the latter you can see how your utopia doesn't necessarily overlap other stakeholders'.

We're certainly not advocating that developers merely code (what's wrong with being specialised?), quite the reverse: we want developers to be architecturally aware. You can extend this to business aware and domain aware too - that's simply not our main area of influence (although we do our best to learn as much as we can).

Like you, we'd like to see teams that see these decisions coming, take responsibility for them and make them based on real information. However, our experience is that teams aren't like this, at least not always at a justifiable cost. Agile's cross-functional team should not be taken to mean a group of equally skilled team members, but a team whose collective skillset can meet the demands of the project.

Re: Re-evaluating software architecture

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).