This is a rehash of a topic I posted about back in 2008 but it is just as relevant today.
When you work towards a release or some other looming milestone. There’s that urge to leave stuff behind, cut some corners – you know, just a wee bit, no harm done – so we can ship the damn thing already. Mostly you’d fight that urge. But sometimes you’d want to make a conscious choice to make a shortcut because, well, sometime delivery is more important
A little drop in quality in a single piece of code will not do much harm…for a while. There are, however, two problems with going this approach. One is that it is a slippery slope, i.e. it is probably not just one piece of code that gets this treatment in your code base. The second problem is … Read More »
(This is part seven of a series. You might want to check the previous parts first)
Parallel and Simplification are the yin and yang of architecture evolution. Simplification, as mentioned previously, is about having foresight and thus provides for,relatively, easy evolution (i.e. architectural additions and not changes). Parallel is about reacting to changes in requirements as they come (no foresight) and making architectural changes.
But wait, architectural changes are hard by definition* – if we make a change to the architecture a lot of things are going to break – starting with the build (or the continuous deployment if you have one) and things will just deteriorate from there. An architectural change will take, relatively, a lot of time and there are a lot of risks in trying to put everything back together. Which is exactly why we need “parallel”.
As the name … Read More »
[Edited: added explanation of the difference between upfront design with iterative implementation and Simplification]
The previous installment in the series talked about leaps as a technique to change the architecture. Leaps are more of a revolution than an evolution and even though they are sometimes needed evolving an architecture is the more interesting topic. This and the next post deal with the two types of evolution strategies Simplification and Parallel. In Part IV I provided the following definition for Simplification (where the base definition is Kent Beck’s and the projection on software architecture is mine):
Simplification – is when you don’t know what you want to do and it is too expansive to directly get to an end result. This is the basis of the iterative system. start small and gradually add features as you go. From an architecture perspective it is … Read More »
When talking about “evolving architectures” a “leap” is one of the worst things that can happen. In the previous installment in this series I defined Kent Beck’s “Leap” design strategy in the context of Software architecture as
“Leap – is for when you know where you’re heading and you can afford to stop everything until the new way is in place. From an architecture perspective it is a bit like starting from scratch. From the practical perspective that would mean breaking the build until a few related changes are in place”
Basically making an architecture leap means that what we did so far is not good enough for us to go forward on. It also means that the current architecture is too far from something useful to bother with taking the more evolutionary approaches to getting it there.
This sounds very … Read More »
If we want to evolve architectures or change an existing architecture in general, for that matter, it is important to understand design mechanics. I recently attended a seminar with Kent Beck that talked about “responsive design”, where he provided a good definition for 5 strategies or types of design mechanics*:
“Just Do it”
Kent talks about these from a design and coding perspectives. Architecture is design but at a higher level and with more consequences system-wide so (I think) are are few nuances from how Kent sees this.
“Just Do it” is what you do when you don’t exactly know where you are going and you so you’re adding features and everything but you probably heading into a big ball of mud. If possible it is better to avoid working this way, but sometimes realities take us there … Read More »
New month new round of tidbits.
IASA Israel chapter 2nd meeting
This Thursday (July 8th) at 17:00 Israel time, IASA Israeli chapter is holding its 2nd meeting. I am going to be there moderating the discussion on Architecture and Lean/Agile projects if you are around Raanana feel free to join
SEI webinar on software architecture
Another software architecture related event going on on July 8th is a SEI webinar on What’s software architecture by Rob Wojcik the webinar will take place on July 8 from 1:00 to 2:00 EDT. Looks like it is going to be an interesting listening if you are new to Software architecture.
Business Analysis Agile survay
Since my blog is also published in DDJ I get a lot of PR requests from all sorts of places, most of them end in my Junk email (if the SPAM filters doesn’t … Read More »
I got several interesting comments to “Who needs an architect” (both here and on DZone). Some of them said I don’t get the architect “role”, some said I am looking at things from the code level and don’t see the forest for the trees, others said that this whole “agile” thing is crap (admittedly not in so many words). Another one talked about the construction architect as a metaphor for software architect etc.
I started writing this post as an elaborate answer to these comments but something was bothering me. Something about the comments sounded familiar , yep you’ve got it – I wrote similar things more than 5 years ago (if you’re interested in the parallels between the presentation to the comments see below). When I originally made this presentation I had about 15 years of experience in the software … Read More »
Not all projects need architects. There, I’ve said it. Not all projects need architects and I am not talking here just about trivial projects. There are cases (maybe even many cases) where you can get by with what I call “off-the-shelf” architecture – maybe with a few adjustments that any master developer (i.e. seasoned and experienced developer) can handle. For instance a lot of web-sites can do pretty well by using Model-View-Controller (or a derivative of that) along with a simple O/R mapper such as active-record. In fact a lot of them do just that, when they use a framework like Rails that made these architectural choices for them*. Another example is the vanilla 3-tier architecture provided by software vendors (such as this one by Microsoft). Yes, when you take something off-the-shelf, the result might not be optimal but that doesn’t … Read More »
Before we talk about the what/how let’s do a quick recap on the why we’re here:
Architecture is important to software projects
Architecture and agile have some conflicting forces that needs to be reconciled (e.g. up-front work, hard to change vs. delivering business value quickly and embracing change)
design can be emergent but architectures can’t and must be grown instead
Another important point to remember is that sometimes you can get away with it. By “get away with it” I mean you can make 1 day or less design session opt for an off-the-shelf architecture, usually that also means choosing a product (e.g. Rails or Django) and it would be good enough for your project. This is usually true for small project or for projects which are ver/y familiar (and thus rather predictive and for the most part can be handled by waterfall processes).
If your project … Read More »
This is part II of a series on agile architecture. You can read part I here.
In the previous installment I provided a definition for software architecture and raised the apparent friction between the up front design implied by software architecture and the YAGNI approach and deferred requirements prompted by agile development in the large. This installment take a look at an additional angle of the problem which is the difference between design and architecture (while architecture is a type of design I cam calling design the code or close abstractions of it that don’t yet fall under “architecture” as defined in the previous post). The difference between the two, as the title suggests, is that while design can be emergent, Architecture, unfortunately needs to evolve.
Unless you’ve been living under a rock, you’ve probably already know about Test Driven Development (TDD) … Read More »