The Blog
Client side architecture
published August 31, 2010
As web applications are getting more web 2.0-ish it is important to build your client side architecture correctly. When you have lots of fancy widgets and desktop-like functionality running on browser, simple html-javascript-hacking will not work. We are currently refactoring our client side architecture and came up with Slideshare presentation by Nicholas C. Zakas about Scalable JavaScript Application Architecture. It has nice concepts that we are considering and it seems to tackle our current issues such as tight coupling, inter-widget-communication and more. I am planning to write in-depth analysis of our architecture and problems that we have had, but meanwhile you should check presentation from Slideshare.
Features that do not fit into architecture
published August 12, 2010
So you got an application. You have analyzed business requirements and coded a domain model that represents business domain from some perspective. You start building features on that model and it all seems to work out pretty well. Then you get the first requirement that does not fit into the domain model and you will have to make a special rule for this case. You decide to solve this by writing logic for it into your UI layer. And so it begins, your code starts to rot.
These “special cases” are very nasty. Root cause for them is usually a mismatch between domain model and business requirement. Building a domain model that can handle beautifully all special rules is very, very hard and will require multiple iterations. However, when you notice a feature that needs a special rule, it is wise to inform your product owner about it and try to come up with a solution that works with current domain model and does not cause your code to rot.
To fix a design flaw or not to fix?
published May 24, 2010
You know the case: a situation in which you must decide whether you should do something about that design smell that was introduced earlier. You suspect that it will not have any effect to a whole system, but still, leaving it like this is not an optimal solution. There is a link at InfoQ.com to a blog post about sufficent design. In short, the blog is about this very same issue, a decision, whether to refactor existing design flaw or not. I feel that this question arises quite often and there is not one correct way to handle it.
The main point with this particular “flaw” is that it was carefully analyzed by a team and a decision was made to leave it as is. For me this is a valid argument to do so. Everything cannot be perfect, but I would like to know how much time the team has spent on the issue? Author states that the issue has been revisited many times, so I have to ask what if the code had been done differently at the first time, would they have saved time in the long run? I find this question intriguing and claim that companies are consuming huge amount of time and money to things that could just be fixed and forgotten. Worst cases are those where a team continually reopens issue without actually doing anything about it.
Shortcuts are unavoidable but they have to be managed. Firstly, you should never take a shortcut if you are dealing with an architecturally core component, that is a sure way to shoot yourself in the foot. If the component can be classified as “not-so-core”, then I see no fundamental error in leaving a minor flaw in the code as long as the flaw can be isolated from the rest of the codebase. Ideally, you would fix it but it is not always that simple. Secondly, I recommend keeping a document about architectural shortcuts that are left in the code. These things have a tendency to be forgotten, so a Toyota-A3-like document is a working way to keep team conscious about shortcuts.
Social representations in IT project
published April 12, 2010
Social representations theory is a popular European social psychology concept by Serge Moscovici. Social representations can be defined as commonsense knowledge about general topics that are the focus of everyday conversations. It is something that can start as a abstract thing like “social media” and then people are gradually starting to understand it by anchoring it to old information. This is something that we encounter also in IT projects, especially at the start. Customer old timers have loads of social representations about the business in form of acronyms, services and requirements that e.g. consultants entering the project cannot be aware of. You know that you have encountered a new social representation when you get a confused feeling while the customer is talking about an important ‘thingy’, but you have no idea what that ‘thingy’ is. Don’t worry, we all get that feeling.
I feel that the start of a new IT project is like a wobbly sphere. Project team is forming, people are encountering new social representations, requirements are emerging and architecture is evolving. The key here is to implement first version of the software architecture and a working vertical slice. Team leader should focus on forming social representations about the goal, requirements and the architecture by referring to these artifacts only with one business related term, so that team can use common language about abstract, software-related concepts. If there are no architectural social representations forming, I suspect that software architecture is a mess.
You also might have have noticed how agile movement has formed it’s social representations about scrum master, product owner, pigs and chickens. Everyone shares common knowledge about these things but we all also have our own personal beliefs and experiences about the very same things. Other key element in the new project is to ensure that team members share somewhat compatible social representations about important things with each other and with the customer. If Scrum means different things to different people I would suspect team to encounter more surge during storming stage of group development.
The architecture that could not work
published November 29, 2009
I had an interesting conversation with our architect about dysfunctional software architectures and their impacts on projects developed on those architectures. I have seen some overly complex software/enterprise architectures that just make simple things too difficult. When project is started to build solution on dysfunctional architecture, it is very hard for it to fill customer expectations and to be productive enough. Sure, every architecture will have its weak points but I am talking seriously flawed ones here. Simplest reason for a dysfunctional architecture can be lack of a architect role for a platform or maybe he just is not competent enough. However, you might have company’s “best architect” on team and still have rough time.
Where did these non-functional requirements came from?
Some harder cases we have encountered are the ones where customer wants to make architectural decisions that will affect whole platform. If these decisions are not sound, we are headed for trouble. Software experts might get instantaneous architecture smell, but it might be hard to pinpoint exactly what problems proposed solution will cause in the future or why it will not work. You get gut feeling that everything is not right here. In these cases it is very important to find out why customer will want to affect architectural decision and to steer discussion towards business requirements behind these ideas. You should never build solutions technology ahead, always discover business needs beneath and design best technical solution for it. It is very important not to commit yourself once you get the smell.
Validating archtecture beforehand
In smelly cases, try to build a proof of concept and experience exactly how it will not work. As stated above, this can be hard without POC. Of course it also could work. To fully explore all possibilities, set-based design (read more here) can be used.
What if customer is so in hurry that there is absolutely no time for a POC? Then I would try to prepare for problems and design system so that flawed parts of architecture are isolated with anti corruption layer, which is easier to refactor later.
Once work has started
It is hard to change foundations of software/enterprise architectures even if everyone sees that selected architecture does not work as planned. We as humans have a tendency to decide a way to solve a problem and keep investing into it, even if correct action would be to discard it and start over. Too often we will not want to admit a mistake. In addition, there can be lot’s of organizational politics behind this. Usually, in these sad cases, money keeps pouring in…
Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
