The Hardest Single Part of Building a Software System Is Deciding What to Build

A quote from Fred Brooks:

The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.

What Must Happen for Schedules to Work

The following is Scott Berkun's list on what must happen for schedules to work

• Milestone length should match project volatility.
• Be optimistic in the vision and skeptical in the schedule.
• Bet on design.
• Plan checkpoints for add/cut discussions.
• Inform the team about planning philosophy.
• Gauge the team's experience with the problem space.
• Gauge the team's confidence and experience in working together.
• Take on risks early.

Adopted from The Art of Project Management by Scott Berkun.

Project Schedules

Schedules serve three functions: allowing for commitments to be made, encouraging everyone to see her work as a contribution to a whole, and enabling the tracking of progress. Even when schedules slip, they still have value.

I like the following Scott Berkun's statements regarding schedules:

• Until there is a draft schedule suggesting specific dates and times for when things have to be ready, it's unlikely that connections and dependencies across people or teams will be scrutinized.
• Schedules force everyone whose work appears on them to carefully think through the work they need to do and how it fits into what others are doing.
• Good schedules come only from a leader or a team that relentlessly pursues and achieves good judgment in many different aspects of software development.
• A schedule doesn't have to be perfect. Schedules need to be good enough for the team and the leaders to believe in, provide a basis for tracking and making adjustments, and have a probability of success that satisfies the client, the business, or the overall project sponsor.
• Despite how perfect and wonderful all the estimates for work items are, the real schedule risks are the things not written down.
• Big schedules should be divided into small schedules to minimize risks and increase the frequency of adjustments.

Adopted from The Art of Project Management by Scott Berkun.

Good Estimates Come From Good Designs

The most important thing about good estimates is that they only come from credible designs and requirements. Good engineering estimates are possible only if you have two things: good information and good engineers.

Here are some additional ways to ensure good estimates:

• Establish baseline confidence intervals for estimates.
• Lead programmers must set the bar for quality estimations by asking good questions and taking wise approaches that the team can emulate.
• Programmers should be trusted.
• Estimates depend on the programmer's understanding of the project goals.
• Estimates should be based on previous performance.
• Specification or design quality should be to whatever point engineering needs to make good estimates.
• There are known techniques for making better estimates. For example, PERT.

Adopted from The Art of Project Management by Scott Berkun.

Software as a Service (SaaS)

Expressed most simply, software as a service can be characterized as follows:

"Software deployed as a hosted service and accessed over the Internet."

It doesn't prescribe any specific application architecture; it doesn't say anything about specific technologies or protocols; it doesn't draw a distinction between business-oriented and consumer-oriented services, or require specific business models. According to this definition, the key distinguishing features of software as a service are where the application code resides, and how they are deployed and accessed.

For example, consider Web-based e-mail services, such as Microsoft Hotmail. It meets all of the basic criteria: a vendor hosts all of the program logic and data, and provides end users with access to this data over the public Internet, through a Web-based user interface.

From an application architect's point of view, there are three key differentiators that separate a well-designed SaaS application from a poorly designed one. A well-designed SaaS application is scalable, multi-tenant-efficient, and configurable.

SaaS is going to have a major impact on the software industry, because software as a service will change the way people build, sell, buy, and use software.

Adopted from Architecture Strategies for Catching the Long Tail by Frederick Chong and Gianpaolo Carraro.

Benefits of Software as a Service

SaaS provides the following benefits:

• Transferring IT responsibilities. A much larger percentage of the IT budget is available to spend on software, typically in the form of subscription fees to SaaS providers. The budget spent on hardware and professional services will be much less.
• Leveraging economy of scale. Even accounting for the hardware and professional services costs incurred by SaaS vendors, customers can still obtain significantly greater pure software functionality for the same IT budget,
• Selling to the long tail. SaaS vendors can offer solutions at a much lower cost than traditional vendors, not only in monetary terms, but also by greatly reducing the need for customers to add complexity to their IT infrastructure. This gives SaaS exclusive access to an entirely new range of potential customers that have always been inaccessible to traditional solution vendors, because it has never before been cost-effective to serve them.

Adopted from Architecture Strategies for Catching the Long Tail by Frederick Chong and Gianpaolo Carraro.

ADO.NET vNext

Carl Perry gave a talk on ADO.NET vNext, the future version of ADO.NET. Frankly speaking, I don't quite understand his talk. Here are some high level recap of his talk:

• Focus on EDM, entity data model
• E-SQL is created and used to query entities
• Support LINQ
• The model is flexible on the provider, the provide could be Oracle provider, or Web services, etc

I don't like E-SQL simply because I need to learn another new language.

The Simpler Your View of What You Do the More Power and Focus You Will Have in Doing It

In his book The Art of Project Management, Scott Berkun states: The simpler your view of what you do, the more power and focus you will have in doing it. I like this statement very much. This statement can be applied to many things. Scott explained it as “Periodically maintain a simple view of our work.” I like to apply it to software requirements and designs.

In the past, I saw that many projects failed because the designers of requirements and designs seeked too much on “perfectness”, fancy, and overly complete. If they can see every detail down the road and the future trend, they are able to design a rather perfect product. In reality, that’s not the case.

Only a small percentage of designers know that it is way better to figure out core pieces of the product, focus on them, implement them first, and even consider releasing them first. Here are some reasons.

First, it’s simpler to do that. A simple math explains that. Assume that you are given three requirements and they are not independent. You might drill down to a dozen of requirements. So you have a dozen of requirements in front of you. You focus on them and won’t MISS any of them. Now assume that you are given twenty requirements and they are not independent. You might drill down to over a hundred requirements. It’s much more complicated to create a design covering all of them and fine tuning all the relationships. It’s very easy to miss a couple of requirements.

Core pieces of your product are much more solid. You have fewer requirements; the project size (for this phase) is smaller; the structure is simpler. These all help on your design and implementation.

It’s much easier to adjust directions according to customer feedbacks. Your design might not be exactly what customers expect. It’s much easier to adjust directions because the product size is smaller and the structure is simpler. You might adjust the priority of your future feature list according to customer feedbacks.

You might earn market share because you release your product earlier.

You might make money earlier to sustain your future development.

You might adopt latest technology in your next phase of your product. Technology changes rapidly, especially on application side. You might expect that there are significant changes every two years. If you phase out, you might apply the latest technology to your next phase of the product.

You should keep one thing in mind: You should design your components in the way that it is easier to extend them.

Let me conclude this post with a quote from Albert Einstein: Any fool can make things bigger, more complex, and more violent. It takes a touch of genius – and a lot of courage – to move in the opposite direction.

ASP.NET Health Monitoring

Erik Reitan gave a talk on ASP.NET Health Monitoring. ASP.NET 2.0 provides an easy way to monitor the health of deployed ASP.NET applications, providing you with detailed run-time information about ASP.NET resources. You might only need to tweak a few settings on Web.config. Awsome!