Book Review: Working Effectively with Legacy Code

Michael Feathers
Working Effectively with Legacy Code

Legacy code is defined by Michael Feathers as code that lacks tests. Lack of tests makes the code hard to understand and difficult to change. When the code is changed, new subtle bugs are often inadvertently introduced. When the code breaks, countless hours are spent troubleshooting.

Does it sound familiar? If you are writing software professionally, the chances are you have worked with legacy code many times before. You may be working with legacy code now. If this is the case, you will find Michael Feathers' book invaluable.

Michael describes practical strategies and techniques to working effectively with both large and small untested code bases. He explains the mechanics of software change and provides insights into adding tests to and ultimately taking control of legacy code.

I recommend this book to all software developers. Happy reading!

Five principles for increasing employee engagement

The following five principles are listed in the Harvard Business Review magazine, March 2010, page 24:

  1. Keep people informed
  2. Listen
  3. Set clear objectives
  4. Match the person with the job
  5. Create meaningful work

Online systems increase transaction costs?

An interesting study was mentioned in the March 2010 issue of the Harvard Business Review magazine. The study suggests that while bank online systems improve customer retention rates, they also increase transaction costs to serve each customer.

The conclusion is rather unexpected, isn't it?

January Architect: Domain Model Structure - Part 3: Repositories

Last time, we continued a discussion around how to organize classes inside your domain model. We defined important domain model elements: Entities, aka Reference Objects, and looked at their relationships. This month, we will review the options for loading Entities into memory.

Potluck Principle of Getting Objects You Want

The Potluck Principle states that if you need to obtain a reference to an Entity in your code, you have the following three options:

  1. You may be able to create the Entity yourself
  2. You may be able to ask another object to give the Entity to you
  3. You may be able to reconstitute the Entity from a previously stored state

Choosing the right option

The option #1 is usually implemented via a constructor or a factory. It works well when you need to create a new entity object, not yet tracked by the application.

As we discussed last month, Entities span through long periods of time and run across multiple systems. Unless you are writing a data entry application, you are going to work with existing Entities a lot more often than with new ones. When you need to create an existing Entity, use the option #2 or the option #3.

Let us take a look at the last month's example: User logs in into the system to check the status of their loan applications. Assuming we have a Person loaded, how shall we obtain their Applications?

Entity Relationship

To enable the option #2, design the Person class with a method or property that returns the Person's Applications. I generally prefer to pass a qualifier, such as loan type or date, that would transform one-to-many relationship between Person and Application into one-to-one with a qualifier, but this is a topic for another conversation. For now, let us assume that the Person class defines the Applications property that returns a list of Applications. This requires you to either get the Applications when the Person object is loaded into memory or implement a lazy load mechanism to defer loading Applications until the Applications property is called.

To enable the option #3, design the ApplicationRepository class with a method that returns a list of Applications for a given Person: "IList FindByPerson(Person person)".

Domain Model Structure

Repositories in the Domain Model

My preference is to place repository interfaces in the model and move repository implementation into a separate Persistence library. Keeping repository interfaces in the model helps clients understand how entities are supposed to be loaded into memory. Having repository implementation separate from the model keeps the model free from infrastructural detail.

Happy coding! To be continued...

The Architect: schedule change

Starting January 2010, articles in our Architect column will be published once every two months. Happy coding!

December book review: Don't Just Roll the Dice

Neil Davidson
Don't Just Roll the Dice: A usefully short guide to software pricing

To download a free eBook, click here.

For the month of December, I picked a short fun-to-read book filled with refreshing yet practical ideas on software pricing. The book is very informative, thought-provoking, and engaging. Will it become something you enjoy reading over the upcoming holidays?

Neil Davidson, the author of the Don't Just Roll the Dice, is a co-founder of the Red Gate Software that provides database tools for developers and administrators. Neil investigates how to make an informed guess at what your product is worth on the market. In the attempt to answer this question, he describes many first-hand real-world experiences demonstrating how a pricing strategy can work to your advantage over your competition.

The book is organized around a series of questions. I listed a few of them below:

  • What is your product?
  • Who are your customers?
  • What is your product's objective and perceived value to your customers?
  • How do people generate their perceived value of your product and how could you increase it?
  • How could you create product versions and bundle your software to increase revenue?

Happy reading!

Silverlight 4 at TCSLUG on Tue, Dec 15, 2009

Who: Shannon Braun
What: Silverlight 4 – A First Look
When: Tuesday, December 15, 2009
12:00 - 1:30 PM
Where: Twin Cities Silverlight User Group
Cost: Free

Registration is required. See more information at TCSLUG.

November Architect: Domain Model Structure - Part 2: Entities

Last month, we started a discussion around how to organize classes inside your domain model in a clear, easy-to-understand, and easy-to-maintain way. We reviewed our objectives and discussed why they are important. This month, we will start revealing a story of a business domain for the purposes of developing a software application. We will look into what is being managed in the domain day to day: Entities.

Discovering Entities

There are a number of technical definitions of an Entity that are popular in the industry. For example, here is a definition from Eric Evans' book Domain Driven Design, p. 89: An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity.

The way I prefer to think about Entities is what we manage in our domain day after day. Entities span through long periods of time and run across multiple systems. They often have lives well beyond our applications and must be effectively tracked. As a general rule, assume that mistakes in Entity identification and tracking are expensive to notice and repair.

To discover Entities in your domain, talk to your functional people and end users. Ask them to walk you through scenarios the new system should implement. How are your users going to use your application? What is important to them and why? What do they really care about? What is important to your company and how does it need to be reported? The chances are you will be talking about what needs to be tracked and how, thus you will be talking about Entities.

Examples: Person, Account, Loan, Application, Payment.

Entity Relationships

What are the relationships between your Entities? Before getting into technical details, create a simple analysis diagram that shows the Entities you have discovered and their relationships. Lets consider a simple example:

Scenario 1: User logs in into the system to check the status of their applications and loans.

Scenario 2: User calls a Customer Service Representative (CSR) to reset their password.

Entity Relationship

Your research and conversations about the domain model revealed 4 Entities: Account, Person, Application, and Loan. Let us walk through the first scenario:

  1. User logs in into the system. The system needs to retrieve the user's security Account and verify their username, password, and any additional validation factors.
  2. Upon successful login, the system retrieves a previously stored Person record based on Account information. Thus, you see an arrow from Account to Person. You learned that each Account has a corresponding Person record, but not all People have created an online Account. That explains the numerical values on the diagram.
  3. Based on Person, the system retrieves their Application and Loan information. Thus, the arrows are shown from Person to Application and Loan. Person is created on the system with their first Application, but not all Applications are approved to become a Loan. Notice that there is no arrow between Application and Loan - we cannot determine its direction based on our current scenarios.
Now, let us take a look at the second scenario:
  1. User cannot verify the security information during login and calls CSR to reset their password. CSR asks them a series of Personal questions and retrieves their Person record.
  2. CSR retrieves the user's Account record for additional verification and resetting the password. Thus, you see an arrow from Person to Account.
Do not worry about having a circular dependency between Account and Person on the Analysis diagram. In one of our next articles, we will show several implementation options for the relationships. We will not have a circular dependency in the final implementation.

Domain Model Structure

Account, Person, Application, and Loan are our first classes in the Domain Model. For now, place them together in a sub-folder under the Domain Model root. We name this folder "Operation":

Domain Model Structure - Operation folder

Summary and Additional Tips

  1. Entity is an object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity.
  2. Entities span through time and space and are being tracked and managed in the day-to-day operations.
  3. Discover Entities by talking to your functional and end users. Create simple Analysis diagrams as a result of these conversations.
  4. Entity's primary responsibility is to maintain its continuity. Keep it simple by leaving complex behaviors out of its class definition.
  5. Managing life-cycle of Entities is a complex and risky job. Try to keep the number of Entities in the system down. Too many Entities will defuse your model and create no value.
  6. Compare Entities of the same type by their identity regardless of their form and history. Make identity type a Value Object.
  7. If you are interested in creating a simple base Entity class, you can start with the one listed below:

    ///<summary>Base Entity Class </summary>
    public class Entity <T>
        public T ID { get; protected set ; }
        public static T NewID { get { return default (T); } }

        ///<summary>Returns true if the object has not being stored in the system. </summary>
        public bool IsNew { get { return Equals(NewID, ID); } }
        public Entity(T id) { ID = id; }

Happy coding! To be continued...

Microsoft released Silverlight 4 Beta

At the PDC 2009 conference, Microsoft announced a beta release of Silverlight 4. The final release is expected in the first half of 2010.

JetBrains TeamCity 5.0 released

JetBrains released a new version of TeamCity, a popular build management and continuous integration server. The release includes a number of important new features:

In the past, if you owned a license to a previous version of Team City Enterprise Edition, you qualified for a free upgrade. Unfortunately, this is no longer the case. With TeamCity 5.0, JetBrains requires you to buy an annual subscription at $999 per year in order to qualify for an upgrade.

The Professional Edition that supports up to 20 user accounts and 20 build configurations is still available at no cost.

Happy coding!

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!