Which tier do you start developing first? Part 2

Part 2, in this mini-series, focuses on which tier to start developing first with a legacy application.

In Part 1, I discussed which tier to start developing first when developing an application from scratch. I'm continuing that post with the next question, which tier do you start developing first when you have a legacy application?

Every application written in this world is comprised of one of the following sets of defined tiers:

• 3+ tiers (wiki) - The last post discussed this.
• 2-tier - Tier 1 has a presentation layer with the business layer contained inside and Tier 2 is the database (or Tier 1 is primarily the presentation layer where tier 2 contains the database AND the business layer).
• 1-tier - Everything is contained in one application.

Most legacy applications use either a 1- or 2-tier architecture. If you are working with a 3-tier legacy application, consider yourself blessed. If you have a 1-tier application on your hands, you may be cursed. The 1-tier applications contain just about everything but the kitchen sink (think of MS Word). It's hard to separate the business layer from the presentation.

Now, with that out of the way, on to the question at hand: Which tier do you start developing first when you have a legacy application?

The answer? It depends.

Legacy developers and teams develop applications to solve specific tasks through software and they have their own style for creating said applications. These programming "styles" sometimes complicate matters and muddy the tier (or is that tear) waters.

My suggestion: 

1. Analyze the legacy app in question and determine which tier requires the most work and match your strongest developer to that tier.
2. Whiteboard the primary areas of the legacy application and determine where each function will reside in the chain of responsibility.
3. Determine if legacy code can be re-used and transformed into object-oriented code.
4. Assign one or two developers to each tier and confirm with each which tier they are focusing on.

If you do have a legacy 3-tier application, here are some guidelines when evaluating each tier:

Presentation layer

• Send your legacy application users a small survey to determine if they think the application works as presented. You may need to conduct usability studies with the application.
• Have they received any errors? If they have, has the presentation layer communicated that back to the servers or just errored out on the main screen with no notification to the team. What if a server goes down? Can you provide a decent error screen without freaking out the user? Uh-huh. :-)
• Do the screens need reworked? Can you streamline the process through better screen layout?
• If secure data is sent over the wire, is the application secure enough when communicating with the Business layer?

Business layer

• Make sure your business processes match with how your business layer functions. I've seen business rules where a supervisor and system administrator was supposed to receive an e-mail when there was a problem. The e-mail went to the system administrator, but not to the supervisor. Instead, the CTO received the e-mail. Whuh-oh!
• Benchmark the communication between the Business layer and the Database layer?
• If the database server is down, do you have an alternative way of saving the data?

Database layer

• Analyze the database and make sure its normalized, and not over-normalized.
• Will the data move to another database server altogether?
• Are the SQL queries optimized?
• Are the error logs easily accessible to other team members?

I'm sure there are plenty of other guidelines to keep in mind when dissecting a legacy application. If you have anything else to add, please do.

Bottom line: An application can be broken into many different "pieces parts", but the as the old saying goes "The chain is only as strong as its links." If one tier breaks, the entire application breaks.