Unfortunately release cycles do not get enough attention so it seems. There are so many external factors that affect a company's release cycle, customer requests / demands, market forces, critical bugs, etc. It seems like timing is way down the list of motivators.
 
We use a 3rd party control set (the name will remain anonymous) and the parent company has not thoroughly considered what a release can do to the developers that use it. For example, they typically release 3 majors a year that contain some sort of bug fixes, new functionality and new controls. Typically they do not release fully regressed hot fixes during the interim but instead they release internal builds. These builds have not been through the full QA process so for a production site they are worthless. That leaves major releases as the only option for us poor developers.

I personally had found several buggy items in their 2nd release of the year so I had no choice but to try the 3rd release (remember no hot fixes). Well in the latest release they decided to change the appearance of the yes/no dialog to remove the no button and make it a link instead (there are plenty of other issues here as well but let’s focus on this one). I know it is not a major change but imagine if I had a 120 page training manual with screen shots or 50+ training videos (this is how we train/support) or a large help file full of the old style dialogs and now I have to go update all my supporting documentation. Maybe it was in the read me file and yes I am guilty of missing it, but the real issue here is their release schedule.

I have proposed what I consider a nice release schedule. One major release a year where all things are candidates for change. User interface paradigm shifts, colors, skins, etc. Then supplement the releases with minor releases that have been through the full QA process along with any hot fixes in the same process. Of course introducing new controls during the year is ok as long as existing controls are not broken. Then we could plan our upgrades appropriately without having to take a major release just because they broke something in the previous one.

Then the life lesson really hit home. One of our vertical markets is extremely busy during March, April and May. So any major UI paradigm shift needs to occur in fourth quarter so our user base will have time to adjust and train on the new components prior to their busy season. What it really means is we have to restrain ourselves as product managers and developers, scheduling the significant changes at the right time for our customers.

Architecture is the big buzz word in the developer community these days. Who doesn't aspire to be an architect. Unfortunately there is too much emphasis on being an architect than on engineering solutions that are efficient and effective. I have a friend that says every application has an architecture the question is did you design it or did it just happen. I tend to agree. These days I describe the development process as engineering a solution, I believe it more effectively describes the process, especially in this world where architecture is over used.

Why do I feel this way? Well as a teenager I was involved in construction, building homes and commercial projects. I was able to observe the people constructing the projects some architect designed. A lot of the time you would hear "that sorry architect didn't think about this or that" and so often the design was "modified" on site. Maybe it was a function of the design being off or too complex but regardless it was modified. I see it a lot in development too. Too much custom work going on in projects to tie everything together. Also it can make estimating projects real difficult. Yeah we have a nice UML model that says this object plugs into that object but when we get to the assembly line we are stuck with a square peg and a hole.

I believe in consistency and uniformity. Everything in the business layer should be designed to look the same, behave the same and expose very similar properties. This solves a lot of problems in the development phase as well in the maintenance phase. As my friend likes to say only about 25% of the cost of the product is in development, the rest is spent on maintenance. Recently I was involved in a large scale development effort and the business layer was really a beast. It seemed like everything was difficult to estimate, implement and maintain. Plus the inconsistencies really became a bottle neck and source of bugs. The next large development process I had control over the data and business layers. I was able to engineer the components to be flexible, generic but type safe and extensible to support all the business entities in the system. The result was a uniform, scalable business layer that is easy to learn yet powerful enough to solve the most complex problems, all with just a handful of core components and a class generator. Engineering was truly the answer.

It seems like all developers seem to believe they are closer to releasing than is reality or at least I always tend to think I'm closer. If you ever need a reality check then just demo your application to a boss, a tester, a friend or business associate. Nothing brings a little light to the subject quite like having to explain your application to another person.

When you find yourself making excuses for problems, lack of completed functionality or functionality in general you will start to realize just how far you are from a completed product. It is way too easy to just brush over the pieces of the application that you haven't worked on for a while. How many times have we left functionality for later or had a design meeting shift our focus to another section of the application. Then as time goes by we minimize the missing functionality and start to think we're so close to launching the product. A good demo will quickly remind you of just how much work is left to knock out. Keep a list of the OH NO moments that occur during the demo just as a reminder of the missing functionality.

A quick way to try out usuability is to have the person follow along in the application. Try talking the person through the functionality in the system without them seeing what your are doing on your screen. You may find that they are clicking on a totally different component on the screen than what you believe. For example we have a calendar for navigation on the right hand side of the application and a scheduler (which now I realize looks a lot like a calendar to everyone else) on the bottom of a split screen. I was instructing our test subject (we'll call her Sally) to click on the calendar to navigate to today's work. Sally would click and report back that nothing was happening. This went on for several minutes and finally I gave up and started a webinar. When I demonstrated the screen to her it became obvious to her that she was clicking on the scheduler. However it also became obvious to me that she viewed the scheduler as a calendar. What was totally obvious to me was a design problem for the average user.

In conclusion what I learned was what I knew...that getting the code in front of people early and often is the best path to developing usuable, successful software. It's just too easy to neglect this principal because we're all too busy building the applications and we let the "less important" items slip.