originally posted at http://www.infoq.com/news/2008/09/architecture-life-span

What is the duration of architectural life span? To which extent this should be taken into consideration? And how may it impact your business? To answer these questions, Dan Pritchett introduces the concept of “architectural shelf life” that he defines as “the duration that a collection of patterns and technology are applicable when starting a new system design”. He believes that architectural shelf life lasts for around 5 years and after two or three generations of it, any architecture has to be changed at least partially. Otherwise, it becomes obsolete and provokes increased costs when it needs to be adapted to business needs evolution. Based on that, Pritchett suggests that “architecture typically has a 10, to at most 15 year useful life”. To support his arguments he provides a series of examples of technology and architecture evolution that have occurred since 1990.

Pritchett argues that failing to update the architecture at the end of its life span may have important implications for business. He acknowledges, though, that making a major architectural shift induces important costs especially when “you have a well established customer base and a overflow of business features in the pipeline”. It can be rather disruptive as it was highlighted by several authors in an opinion exchange about architecture rewrite. However, Pritchett argues that the non-adoption of new patterns and technologies can be ever more costly. They most often help to improve developers’ efficiency and to lower costs of deployment. Renouncing to exploit this potential competitive advantage equals leaving competitors the initiative to do it and this can be fatal for business:

What is missed is that the new patterns and platforms can be used to disrupt your business anyway. If you have a successful business, many others want a share. And technology becomes the tool they can use to go after your business. And the disruption they can cause by offering your services at lower cost or with more compelling features is far greater than any disruption that will be incurred for internal architectural shifts.

In his follow-up to the first article, Pritchett brings some nuances to the inevitability of major architectural shift as new patterns and technologies emerge. Having already said that the life span of architecture depends on its ability to be easily extended to the evolving business needs, he translates it into technical terms as ability “to be refreshed with new technologies in an incremental fashion.” This ability can be increased by “following standard architectural principles of good component design with the loosest possible coupling between components” so that they can be implemented and evolve independently from each other. Based on common mistakes that he could identify, Pritchett extracts some principles to adopt in order to build more long-lasting architecture:

1. Decoupling of interface protocols from an implementation strategy. This increases the “flexibility for migrating components to alternate implementation technologies”. As a way to achieve that, Pritchett suggests building text based interfaces between components, such as for instance XML or JSON.

2. Respecting separation of concerns, even if initial size of the two concerns is rather unequal. This allows avoiding situations when a new feature is added to an existing component and as this feature grows bigger, you end up with two components implemented as one, badly coupled, intertwined and extremely difficult to uncouple especially since “customers have come to expect a behavior that will be hard to maintain if you decouple”.

3. Avoiding unintentional vendor lock which requires deep understanding of the behavior of vendor’s products, their impacts on the architecture and its implications.

4. Minimizing persistence binding in order to avoid database lock. Only the primary access path to any entity should be via primary key and all other access paths should be separated in the resource tier so that the alternate paths can be managed in other forms of persistence in the future.

Following these rules to minimize coupling allows building flexible architecture that can rather easily integrate new technologies and patterns, thus reducing the cost of changes and increasing architecture’s life span.

http://www.infoq.com/news/2008/05/software-rewrite-4-architecture

As it gets more and more difficult to adapt software to new demands and requirements, the temptation to rebuild it in order to update the architecture grows stronger. The undertaking being rather risky, it is crucial to adopt the right tactics. Andy Singelton’s recent blogpost provides some insights into different tradeoffs in terms of cost, technical complexity and potential commercial risk that should be considered while choosing one or another strategy. He identifies three possible approaches and briefly highlights advantages and disadvantages of each of them:

- the “prototype and expand” option that refers to writing full new software;
- the “incremental” option based on updating some components and refactoring while still using your code base
- and the “buy” option that consists in acquiring existing software that meets new requirements.

However, several authors in the blogspace argue that the first option – rewriting software from scratch – should be avoided at all prices. Joel Spolsky advocated against such approach back in 2000, in the wake of the announcement of Netscape 6 release. He qualified the decision of Netscape to rewrite the code as “single worst strategic mistake” and provided some more illustrations of similar “mistakes”: dBase and Quattro Pro of Borland as well as Microsoft’s Pyramid project. Joel believes that in many cases the perceived need to rewrite software is very subjective and is often related to the inherent difficulty of code reuse. Moreover, he argues that much of what makes code less readable is actually related to the long process of real world testing and bug fixing:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. […]

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. […]

Each of these bugs took weeks of real-world usage before they were found. […]

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Joel Spolsky also stresses potential business risks of launching a rewrite project that would undermine the capacity of the team to respond to emerging market needs. Hence, according to him, even if the old code base is really bad in architectural terms, one should go for cleaning up code, refactoring and changing interface rather than launching a full scale rewrite.

One of common arguments for rewriting software is the assumption that with experience that has been gained since the first release, the team would be able to do a better job? However, Joel Spolsky highlights the fact that the developing team would most probably have changed over time. Moreover, as it was stressed by Dharmesh Shah, who more recently echoed at Spolsky’s article, there are great chances that market conditions would be changing too.

Dharmesh Shah lists other common justifications for software rewrite – e.g. bad code base or wrong initial choice of the platform or the language – and shows their limitations. He elaborates on reasons why one should resist the temptation of launching a rewrite: the process will inevitably be longer than expected; there is a major risk of not being able to respond to potential market changes and demands from existing costumers, which may undermine the competitive advantage of the software; and there are alternative solutions, e.g. refactoring that is instrumental for cleaning up the code while reducing the previous risks. Dharmesh Shah believes that rewrite is justified in only few cases: if initial technology choice prevents you from commercial success or if there is a huge shift in technology landscape – e.g. from client-server to web-based computing” – and your software cannot adapt to it.

Based on his experience of porting Quattro Pro from Modula-2 compiler to Turbo Pascal, Bob Warfield, who commented on Dharmesh Shah’s post, believes, however, that it is not worth rewriting software to change languages. He also dds some other insights on the issue, i.e. the importance of human resources especially if the decision for rebuild is taken because of the poor quality of the existing code. He further emphasize the value of refactoring suggesting that it can go beyond code and that the experience gained by the team can be used to refractor, for instance, the user model.

The first time I got introduced to mutation, I had a bad feeling. How can x:=x+1 be logical at all?

It felt so unnatural, scary, or maybe like a hack. Then, because of society constrains, I got to forget the bad feeling about that. Well, my mind started to tolerate with counter-logic logic. And that is how I became an enterprise developer. I am not sure how proud I am with this title anyway. I feel that tolerating and accepting the counter-logic logic is one, and most important one, of the prerequisite to this title.

Nowadays, I am working on a project that has to process a huge number of data to do calculations on it and produce results that make sense to the user. Performance is a constraint. And I decided this time to do it the right way, the way that I believe is right. The logical way.

I decided to the calculations with no mutable state. I wanted immutability to be my guarantee to safety. Mutability breaks logic, and so produces bugs. But I couldn’t imagine how hard this choice can be. You tend all the time to feel that it is easier to introduce a mutable object, mutable flags, temporary mutable containers inside loops. Imperative programming is so tempting. Just like drugs. It feels so strange and weird in the first time, but then, it becomes a habit, a bad one, and you can’t help but to break into it. Mutation and imperative programming is the simplest thing that work in some way.

Today, I am happy I almost finished the whole calculation logic I had to model ( and it is quite a complex one). And I am proud that I could resist introducing mutability in the algorithm. Yet, I did some experiments along the way to introduce just a bit of state, kind of just what I need to introduce faster one kind of calculation. This very small mutation just breaks it all. It just breaks the whole modularity of the algorithm, and just makes the whole calculation much less generic, and more importantly less maintainable and evolutive. Such a small mutation, like introducing a mutable flag, or a global variable, just breaks the whole logic of my calculation, and drives me far away from a good modular calculation, with a good design based on plain old principles of separation of concerns. It just makes impossible to go further with the implementation! It is like a cancer of code…

Now, after the discipline and the resistance to a mutable state, we are so happy with the resulting code that yet needs polishing, makes it very easy to parameter more calculations and so add more desired functionality to the program. And just for fun, we compared it to the same calculation done with imperative programming. It is much more concise, intention concealing, and as a result, surprisingly we paid no performance cost for a much more declarative code.

I owe a lot to Erik Meijer, Paul Hudak, Linq, and Haskell :)

http://www.infoq.com/news/2008/02/scalability-dynamic-vs-static

First of all, Neward emphasizes that a language scaling can be understood in terms of "size of project, as in lines-of-code" or in terms of "capacity handling, as in "it needs to scale to 100,000 requests per second"". The two need to be delineated because even though both are important, they do not always go hand in hand: assembly languages or C, for instance, are conducive to capacity scalability but not to size scalability.

Neward defines size scalability in terms of “a language’s ability to extend or enhance the complexity budget of a project”. He refers to Mike Clark’s concept that implies that “every project has a fixed complexity budget, and the more you spend on infrastructure and tools, the less you have to spend on the actual business logic." And according to Neward, this point is at the core of the debate about the scalability capacity of static and dynamic languages.

The adherents of static languages argue that type-safety check results in fewer work for the programmer “as an automated tool now runs through a series of tests that the programmer doesn’t have to write by hand”. Moreover IDE support that exists for these languages provides powerful tools for refactoring that are “widely believed to be impossible on dynamic language platforms.” Dynamic language proponents, however, put forward the fact that “the dynamic nature of these languages means less work during the creation and maintenance of the codebase, resulting in a far fewer lines-of-code count […] thus implicitly improving the scale of a dynamic language”. 

According to Ted Neward, it is true that “dynamic language programmer can typically slam out more work-per-line-of-code than his statically-typed compatriot”, but he will most probably need to produce more unit tests given that dynamic languages do not use a compiler that, in a way, ensures a certain number of systematic tests. 

As for IDE refactoring, Neward references Dave Thomas who admits that refactoring support of Eclipse, for example, is limited for dynamic language platforms given that type information is missing until runtime. Thomas highlights, however, that “simple search-and-replace across files, something any non-trivial editor supports, will do many of the same refactorings as Eclipse or IntelliJ provides, since type is no longer an issue.” And Neward emphasizes that he expects IDE vendors develop tooling specifically designed for dynamic languages:

[… ]it’s relatively easy to imagine that the IDE could be actively "running" the code as it is being typed, in much the same way that Eclipse is doing constant compiles, tracking type information throughout the editing process. 

Moreover one should not forget that “the original refactoring browser was an implementation built for (and into) Smalltalk, one of the world’s first dynamic languages”, as it was highlighted in the TSS debate.

With respect to capacity handling scalability, Ted Neward stresses its importance because “a project that cannot handle the expected user load during peak usage times will have effectively failed just as surely as if the project had never shipped in the first place.”  

Dynamic language opponents argue that these languages cannot scale in terms of capacity handling, because they are “built on top of their own runtimes, which are arguably vastly inferior to the engineering effort that goes into the garbage collection facilities found in the JVM Hotspot or CLR implementations.” Dynamic language supporters respond that “there are plenty of web applications and web sites that scale "well enough" on top of the MRV (Matz’s Ruby VM?) interpreter that comes "out of the box" with Ruby”. 

Ted Neward, at his turn, points out that “with the release of JRuby, and the work on projects like IronRuby and Ruby.NET, it’s entirely reasonable to assume that these dynamic languages can and will now run on top of modern virtual machines like the JVM and the CLR”:

While a dynamic language will usually take some kind of performance and memory hit when running on top of VMs that were designed for statically-typed languages, work on the DLR and the MLVM, as well as enhancements to the underlying platform that will be more beneficial to these dynamic language scenarios, will reduce that.

Ted Neward seems to believe that there is a window of opportunity for improving scalability of dynamic languages in terms of both project size and capacity handling by adapting tools and optimizing runtime environments to their specificities. More generally speaking, he rather opposes the dichotomy between static and dynamic languages. He highlights the fact that some applications, Excel for instance, successfully combine the two "by creating a core engine and surrounding it with a scripting engine that non-programmers use to exercise the engine in meaningful ways.” Neward sums up rephrasing Karl Marx: "From each language, according to its abilities, to each project, according to its needs."

• In agile development process, the Design task is still important, we just changed the way we do it to evolutionary design rather than un upfront one. Yet, In some cases we cant defer design decision till the end, and we do need to do them in an upfront style. 

Do the simplest thing that works ( Kent Beck )

• Kent Beck commented on this that “The simplest thing is not the most stupid !”
• Software SHOULD have a model, and cant be only tachtical all the time.
• In a Lean Software Development we dont make decisions before we really have to, but we have to do them once! or otherwise we will be taken as not able to make decisions.
• Try different choices on different teams, building different implementations, find that last minute where you can decide.
• The key to modifiability is encapsulation and abstraction.
• The key question is : Do i have to make the decision yet?
• The Domain Model is made! The task is to reflect it well in the software.
• Isolate Domain models from technical ones
• Preparing a ground for Modifiability
• Making a decision of when to make a decision
• Discuss well with business people to reflect the model
• Html is undoable because there is not a ig investement in doing it
• Breaking encapsulation for a decision makes it a bad decision
• redability of code
• Unit testing to guarantee encapsulation
• Software evolves anyway, maintainability IS an issue!
• Encapsulation is about keeping secrets.
• Pair progamming for teaching design, that will raise team’s productivity as a whole
• Lessons can be learnt better through modifiability than through upfront teaching
• Struggle for reversable architecture