reference architecture

Team Foundation Server (TFS) 2010 Branching Guide

The following guide is a very helpful resource. I recommend that you read it and determine the branching strategy that you want to use before you setup your team projects.

http://tfsbranchingguideiii.codeplex.com/

Reuse Practices

Here are some key software development reuse practices:

• strong software architecture that provides framework for reuse activities
• software development process that promotes and controls reuse
• reuse more than just code; reuse at the architectural level
• practice domain engineering; develop reusable components at the domain level
• integrate reuse through all of the life cycle activities and the management of those activities
• use software tools that support reuse; modern IDEs along with supporting knowledge bases are very useful.
• organizational structure that facilitates partnering across project boundaries

Reuse can occur at many levels. Some of the levels, starting at the lowest level and working up are:

• code fragment (cut and past reusability)
• subroutine or function
• object (data and methods)
• component
• architecture
• business patterns
• packaged application frameworks

Effectively reusability doesn't just happen. It is a planned event that takes time and resources. A separate domain engineering and knowledge base is required to promote and push its use throughout the organization.

The problem with reusability is that it usually isn't cost effective until a component has been reused (with very little analysis or modification) 5 or 6 times. Designing components for reusability slows down the current design and implementation process and requires a domain engineering/knowledge sharing organization to support and carry-on the reuse efforts.

Reuse is most effective when it is tied to business or technical patterns. The lower the level that reuse occurs the smaller its payback. This is because the first four (4) levels that I listed above only affect the implementation or coding cycle. Architectural and business patterns and customized packaged applications cut across many more of the software development lifecycle (SDLC) cycles and therefore have a larger impact.

Big Projects, Done Small - Computerworld

I agree with the premise of this ComputerWorld article by Frank Hayes - "propose big and build small".

Just make sure that you don't follow a huge waterfall methodology. This approach requires an agile methodology.

As you implement additional portions of the system you will have to revisit and refactor portions that you already finished. Don't stress out over this.

Change and release management are also important parts of making this approach work.

Simplicity versus Complexity

[Note: Originally posted on "improving outcomes blog" on 2Mar2010.]

Simple is hard.

It is much easier to do things the complex way. It takes very little thought about what you are doing or how you are doing it if you don't care about the complexity of the process or the resulting product.

As Abraham Lincoln said, “I'm sorry I wrote such a long letter. I did not have the time to write a short one.”

Mark Twain is also quoted as saying, "I didn't have time to write a short letter, so I wrote a long one instead." [update 8/23/10]

So, if complex is easier and faster, and simple is harder and takes longer - why do I want to simplify?

As I have discussed in previous posts - it comes down to the difference between ad-hoc and repeated-use processes and products. The difference between designing/optimizing and executing/maintaining.

If a process is performed just once or if there is only a single implementation of a product then there is little benefit to simplicity. These are truly ad-hoc processes and products.

For everything else, the answer is quality. Quality attributes like functionality, reliability, availability, usability, efficiency, maintainability, and extensibility.

It is hard to get the results you want on a reliable and repeatable basis using complex processes and products. Complex processes and products have more failure points and break down more often than simple ones. And, when they break down it is difficult to find the root cause of the error and fix them. It is also very hard to learn complex processes and products and become efficient using them. Finally, complex processes and products are difficult to modify or extend to support changing needs.

Where does complexity come from? It can creep into your processes and products in many ways. A few ways are:

• Converting ad-hoc processes to organizational processes.

• Designing without the real end-user in mind.

• Layering governance processes onto organizational processes. This is also know as the bureaucracy factor.

• Poor implementation, including training, of organization processes.

Two key approaches to remove complexity are:

• Design all processes and products with the focus on the end-user. Understand the needs of the end-user and meet those needs as simply as possible.

• Only add tasks, features, and functionality to your process and products that are absolutely required. Also, remove any that are no longer required. Leaving unnecessary bloat in your processes and products are a big cause of complexity.

References:

1. Harvard Business Publishing Webcast - Take Complexity Out of Your Company, with Ron Ashkenas, author or Simply Effective.

Is Your Business a Journey or a Destination?

[Note: Originally posted to "improving outcomes blog" on 22Feb2010.]

"Life is a journey, not a destination." - Ralph Waldo Emerson.

A destination is (Collins English Dictionary):

1. the predetermined end of a journey or voyage
2. the ultimate end or purpose for which something is created or a person is destined

Life is like a roller coaster. There is a beginning and an end - and they are both the same place. The goal of riding the roller coaster is not to get back where you started. It is to enjoy the wild ride in between.

Businesses also have a life line. They are formed and they are dissolved. Their goal is also not some predetermined or ultimate end. It is the value that they provide to the people they encounter along the way. Because, if a business reaches an ultimate end and then remains static it will soon cease to exist. As I stated in my "Dynamic versus Static" entry on 1/26/10, businesses must remain dynamic to continue to exist and provide value.

I don't think that many people consider the end of their life or the day they dissolve their business as their goal. However, many do forget that it is the journey and not the end result that provides the reason for existence. They rush through everything they do without really experiencing, enjoying, and learning - as if they are on a race to the end.

The same also applies to activities and milestones along the way. A milestone is (The American Heritage Dictionary):

1. A stone marker set up on a roadside to indicate distance in miles from a given point
2. An important event, as in a person's career, the history of a nation, or the advancement of knowledge in a field; a turning point

Goals and milestones are important metrics to keep your journey on track and make sure you are headed in the right direction. It is still important to remember that it is everything you do and learn on the journey that is more important than the goal or milestone.

Take school for example. If your goal is getting a diploma as quickly and easily as possible then you are missing the real purpose of an education. The real purpose happens during the journey, the more you take advantage of all your opportunities to learn as much as possible, instead of the minimum, then the better prepared you will be when you complete your studies.

The same thing also applies to projects. If you approach each project as only a quick and easy end goal then each project will be new and exciting but will not provide lasting benefits beyond just getting it done.

I am not saying that quickly, efficiently, and cost effectively are not important attributes of a project. Or, that getting to "Done" is not important. I agree with all of the points of "The Cult of Done Manifesto". In fact, it is because I agree with them that I believe the journey is more important than a procrastinated or perfect done.

Process improvements and quality programs are based on the journey. They measure the end product; but, to realize improvements, changes must be made to the process followed during the journey.

You must learn both during and from the journey in order to mature and improve.

Using Checklists

[Note: originally published on "improving outcomes blog" on 2Feb2010.]

Checklists are not a new concept. However, they have been generally under-appreciated for the benefits they can bring to complex tasks in a simple and unobtrusive manner.

In many situations people try to over-specify and over-control processes with lengthy policies and procedures that no one reads, remembers, or follows. It is not that these policies and procedures are bad, it is just that they need to be accompanied by simple checklists that ensure that the key policy goals are being met.

Here is a checklist that we used for our Change Control Process. It was used to ensure that you were prepared for the Change Control Board meeting. If you came to the meeting with this checklist completed then you would quickly get approval to move forward. Download Change Control Form.

I haven't personally read it yet but The Checklist Manifesto: How to Get Things Right by Atul Gawande (Dec 2009) revisits the power of the ordinary checklist. You can listen to the Harvard Business IdeaCast, Using Checklists to Prevent Failure (22 Jan 2010), which is an interview with the author. A commentary on the book can be found at The New York Times: Freakonomics Blog: The Checklist Manifesto.

The following research and information about checklists are also very useful:

• The Logic and Methodology of Checklists by Michael Scriven (2000, 2005, 2007).
• Guidelines for Developing Evaluation Checklists: The Checklists Development Checklist (CDC) by Daniel Stufflebeam (2000).
• Western Michigan University, The Evaluation Center - Evaluation Checklists
• Warren Buffet Disciples Using Checklists to Improve Investment Results (24 Jan 2010).
• Using Checklists to Evaluate Risk Factors (8 May 2002).
• Using Checklists to "Standardise" Content (2 Feb 2003)
• Helpful checklists for students (2 Sep 2009).

Evolving Database Design

The concept of the "golden" and immutable database schema makes me crazy.

Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.

However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)

Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".

In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.

In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).

Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.

Lean Modeling (or, there are sure a lot of UML diagrams)

In UML version 1.4 there were 9 diagrams.

In UML 2.2 there are now 14 diagrams. There are seven structure diagrams and seven behavior diagrams. Within the behavior diagrams four of them are interaction diagrams.

But, this entry isn't really about the number and type of UML diagrams. It is about lean-modeling using UML. As I mentioned in my entry on Modeling Philosophies, over-modeling is worse than under-modeling. What you really want to achieve is just-what-is-needed-just-in-time modeling.

You have been asked to develop the software architecture for a new system and to document it for presentation and review. And, by the way, use UML diagrams. What do you do? Throw your hands up in exasperation and complain that you don't have enough time to do 100's of pages of documentation?

No.

To start with, let's assume that you were going to do some analysis and design before you started coding. The UML models should flow naturally from your analysis and design process.

You are going to need to determine what things/nouns/objects/entities you are going to be working with. Document them in a class diagram.

You are going to need to determine what actions the user or other systems can cause or trigger. Document them in a use case diagram. If the actions are not self-evident then provide more detail using activity diagrams.

If an action is complex and requires coordination between multiple objects then you may want to create a sequence diagram to illustrate the interaction between the objects.

If you have a process flow with a number of states and each state can transition to multiple other states then a state machine diagram is very useful.

I also recommend that you develop a package diagram for your system. It will help you determine how to structure your code/solution, group your objects together for deployment (dll / jar files), and avoid cyclical references.

Finally, I am not saying that you shouldn't use any of the other diagrams. Depending upon your application type, its complexity, and your audience, additional diagram types may also be very useful.

Four Phases of RUP

Are you having problems determining which phase you are in and what your focus should be?

Forget the standard names:

• inception
• elaboration
• construction
• transition

Use the following questions to determine if you are on track and to remind yourself what you are trying to achieve:

• Should we build it?
• Can we build it?
• Is it built yet?
• Is it delivered yet?

When you have answered yes to the question for that phase it is time to move to the next phase.

If you realize that you will not be able to answer yes to a phase, within your time and budget constraints, then it is time to kill the project.

No one likes to fail but not everything is possible and killing a project at $1mil is a lot better then doing it at $10mil or $100mil.

Agile and Iterative Development

"The deliberate march toward delivery is the hallmark of true iterative development." (author unknown)

To me it doesn't matter which software development life cycle or methodology you use. It is more important that you adopt agile principles in your execution.

Principles like those laid out in the "Manifesto for Agile Software Development" and "12 Principles of Agile Software".

I have worked as a Unified Process / Rational Unified Process consultant, mentor, and trainer for many years. In practice I always favored Scott Ambler's philosophy that documentation is for communication and to keep it to the minimum amount required for the project.

On smaller projects, under six developers, I found myself following more of a Scrum-like process and it worked out well.

Now that there is a good Scrum template(Visual Studio Scrum 1.0) for Microsoft Visual Studio and Team Foundation Server I have completed my Scrum conversion.