September 2006 Entries
The other day I was looking to see if any new podcasts had popped up around .NET Development or Software Architecture. Well I did find one. Net Objectives has started (OK, they have been doing this since May) a podcast on Lean-Agile. I have only listened to the first episode so far. While the host, Jim Trott, has a monotone, metered presentation I was impressed by his conversation the company's founder Alan Shalloway.
In the first episode Alan gives one of the best descriptions of Agile development that I have ever heard. I would have to say at this point that the series is worth the time to continue to evaluate it. It has a lot of promise.
Tom Hollander has posted what the initial feature list of changes for the next version of the Enterprise Library will consist of. One item on the list made me think that they have really taken on a challenge. There is a new application block proposed for validation. I look at things like the client side validation control and the business rule scheme that Rocky uses in CSLA.NET and I just wish I could be a fly on the wall when they go to build this. It is going to be fun to come up with a solution that is flexible enough to cover a large number of scenarios and still perform. Good luck guys.
I saw this post
and it got me interested. I looked through some of the topics and they seem like they would be valuable. I can't tell from the site if any of these are in English. If they aren't I would like to see them presented as such as well. Any alternate resources or viewpoints are always welcome in the architecture space.
An associate of mine at Daugherty has started to blog
. It will be interesting to see what topics he decides to cover. I know that lately his interests have been around message queues. Good luck Ahsan.
has done is usual outstanding job with the latest installments of his Polymophic Podcast
. The last two shows have been a thought provoking interview with Miguel Castro
. In it they discuss design patterns that can be used to allow for greater flexibility and extensibility when building applications. This is a topic that has interested me for a while now, especially patterns such as Dependency Injection which give the ability to define at run time the way that an application will act. So take a listen and check out Miguel's article in Code Magazine
(I admit I have only started reading it). You may find new ways of thinking about you application designs.
As architects it is our job to think things through. We are paid to work out possibilities and evaluate issues in the context of what already exists. I was reminded of these facts the other day when a couple of developers brought an issue to me where they were saying a product was not capable of producing the required results. A knowledgeable developer on that product said we would have to create extra custom components to get around this “feature”.
I quickly jumped into scramble mode and started alerting the project manager that there was a possibility for unplanned work. Luckily I prefaced it with the fact that I was still investigating. Afterwords I was talking with another architect who reminded me that part of the problem had already been addressed with an earlier change request. It was one of those “duh!“ moments. Another bullet dodged.
It just goes to show that we all need reminders some times of how we need to approach issues.
Scope reduction in a project is generally seen as a positive activity. In small applications this is generally true. This is not always the case though, especially in an enterprise environment. The key determining factor is the down steam impact of removing the feature from scope.
If the item has already been planned for by other project teams the rework could be more expensive then what is being saved. Does eliminating the task mean that other applications need to plan for development or processes to cover the gap. The requirement needs to be of an isolated nature such that the only effect is to that particular component. At the least the impact needs to be understood and acknowledged by the stakeholders.
As with most decisions on a project you need to weigh the benefits and the costs. Along with the collateral damage you should also consider the long term implications. If not implementing something now means implementing it later at a higher cost you may want to reconsider. Be a surgeon and not a lumber jack. Only cut away what you have to.