The Blog
Strangling legacy code
published November 30, 2009
How do you refactor a legacy module which is used by many clients? Well, you strangle it. In a picture below we have two clients using some legacy code that we want to get rid of.
You start by creating a new interface and switching part of the usage to that interface.
Gradually, you refactor parts of your legacy code and move more clients using the new implementation.
In some point, you have managed to move all usage from the legacy interfaces to the new implementation, but you still might be using the legacy implementation under the hood.
The final step is to completely remove legacy code once you got all your necessary features refactored.
And actually delete all your legacy code, I do not want to see huge code blocks commented out “just in case we need this in the future”. You don’t. And if you do, you still find it in your SVN, right?
Differentiating between bugs found in a quality control and those delivered to a customer
published
In our software delivery process at the current customer we end our sprints to a production release. This is a very nice way to keep iterations compact and to minimize huge testing effort before deployment. So, how do we keep track of the bugs that are found inside a sprint by our own quality assurance and those that are shipped to the customer in the new release? We use custom issue types for Jira.
We create the bugs found inside the sprint as “notices” and the shipped bugs as “bugs”. This way we can easily keep track of how our quality control process works, what is the ratio between the notices and the bugs, and to track exactly how much time is spent on a bad quality. This important data is later used in sprint planning to make sure we have reserved enough time to fix notices before the next production deployment. This is a must if you want to release quality software at the end of every sprint.
No early risers in your team?
published
A Classic way of getting people in time for mornings scrums is to agree on penalty for being late. Sing a song or bring doughnuts, it can work. I just finished watching of a documentary about biological clocks. Program was about chronobiology that is a study of cyclic phenomenas in living organisms. According to documentary it is possible to shift your internal clock by decreasing light intake in the evenings and increasing it in the mornings. This way your biological clock will make it easier for you to get up early. No more spending money on Berliners, save it for Diesel shades and Philips wake-up light.
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…
Keeping your development environment in sync with production environment
published
In one of my current projects, we are developing a semantic portal that is providing welfare related information for public. Portal content is updated daily by content providers while we are developing more features using three week sprints. We have a very nice way of keeping development environment in sync with production environment.
1) In the beginning of every sprint, production content is copied into the maven repository using custom made scripts.
2) Test environment data is brought up to date with the production environment.
3) Development environment content data dependency is updated to latest version in our pom.xml files.
4) Developers update their environments from the SCM and the Maven repository. Development data is now in sync with production data.
5) Developers start to build new features planned for the current sprint.
6) Once a feature starts to be ready, new installation is made into the test environment and a developer will make necessary configurations for it.
7) Tester works with developer to finish the feature. In our team, tester is a role and can virtually be anyone.
8) Test environment content is copied into the Maven repository using custom made scripts.
9) Development environment content data dependency is updated to latest version in our pom.xml files.
10) Developers update their environments from the SCM and the Maven repository. Development data now contains just finished feature.
11) Steps 6…10 reoccur n times.
12) Once all features are ready (or we run out of development time), testing begins. During this time, only bug fix commits are allowed as we are getting ready for the production release update.
13) Production deployment is made for the new release.
This cycle works well and this way we are developing against latest production data. Key here is to make export and import scripts very easy to use. This style will help you tremendously if you are planning to release after every sprint.
From norming to performing
published November 26, 2009
Bruce Tuckman’s small group theory “Forming, storming, norming and performing” is a group development model created in the 1960s. It tries to model group behavior and small group development while group is doing something e.g. solving a problem.
I have seen group development in action many times and while there are other theories, I think Tuckman’s model is close to what I have experienced. Somehow I just feel when a team enters the norming stage and especially when it enters the performing stage. In the early stages, it just feels that things could be done much, much better. In order to reach high performance state, it is critical to keep building the team day by day. Usually it will pay off and finally the team will knit together and function very well. Sometimes, unfortunately, the team will not reach performing stage.
It is a shame that performing stage is often reached close to the end of a project. This is why I feel it is effective to try to move whole team to a next project as a unit. They will automatically produce more value from the start of the next project as they have bypassed the forming and the storming stages earlier. Of course, it is not that simple that once a group has reached the performing stage, it will maintain it forever. A highly productive team may revert to storming in some cases.
Anyways, it is a very pleasant feeling to be a part of a high performance team.
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)
