Whiteboards for Everyone!

Do you like designing on whiteboards?  I do.   Colorful markers against a clean, white surface inspire all kinds of creativity and fun.

Recently David Crossett of Ready Receipts gave me a great tip.  He told me that instead of going to your local OfficeBOX superstore and paying $200 for a 4×8 whiteboard, just hit HomeDepot instead and get a $12 piece of showerboard.  It works just as good and if you need a smaller size they will cut it for you on site for no additional charge!  At that price, you can line your walls with thinking space.  Power to the Consumer–thanks David!

Mike J. Berry
www.RedRockResearch.com

Don’t miss these Software Development Best Practice Workshops…

I’m hosting weekly Software Development Best Practice workshops each Thursday during the next four weeks.  These are held during work hours so ask your manager/VP/CIO and perhaps they would like to come along.  The topics are different each week.

This is basically a summary of my three day courses that I am now offering.  I’m giving the info away to get some attention in the valley.  Each workshop is from 3:00 – 5:00pm Thursday afternoon at the Miller Campus – Professional Development Center  This represents a tremendous value as I have put over 3000 hours of research into the material and consumed over 100 industry books.

Topics

Software Estimation – July 9th

Software Requirements Management – July 16th

Software Quality Systems Management – July 23rd

Software Development Life Cycle (SDLC) Management – July 30th

Event Calendar and Info

http://www.utahtechcouncil.org/Events/Community-Events/Community-Calendar.aspx

Hope to see you there!

Mike J. Berry
www.RedRockResearch.com

Anatomy of an Execution Plan

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here’s an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  OnLine Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system’s business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the ‘rollback point,’ which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to ‘check’ completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a ‘lessons learned’ section to be completed later, and keep a copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

Software Production Support

In a conversation with a friend once, they jokingly described their inability to play racquetball against other seasoned players as “They are playing racquetball, while I am just hitting a ball around the room.”

I’ll borrow that reference and apply it to Software Production Support.

Is your Software Production Support group “playing racquetball,” or are they “just hitting a ball around the room?”

From a distance they can appear like the same activities.  On closer inspection however, one is much more organized, elegant, patterned, and proactive–while the other is only reactive.

Finding the order from all the choas separates the effective from the ineffective.

There are three particular areas your Software Production Support team should be focus on.  These three areas are:

1. Maintaining Systems
2. Managing Customer Expectations
3. Become a Quick-Reaction Force

1. Maintaining Systems:

Think of your production servers like a fleet of cars.  In a fleet plan, the company sends every car to get an oil change after x number of miles, a tire rotation after y number of miles, and a general tune-up, fluid change, etc. after z number of miles.  This pattern repeats itself for the life of the car that is serviced by the fleet manager.

How often are your server hard drives defragmented?  How often are the transaction-logs backed up?  How often are the indexes reindexed, and the statistics updated?

How often are memory settings adjusted for performance? Latest patches applied? How often are your servers checked to see if there any impending disk space issues?

To maximize system performance, create a “fleet plan” for your servers which checks all of these items at regular intervals.

2. Managing Customer Expectations:

If a server fails, do you know which systems depend on it? If a database goes corrupt, do you know which applications need it, and which corresponding business units will be impacted when that happens?

Do you have a way to communicate to those groups immediately?

Create a dependency map for your products.  A dependency map illustrates which servers host which databases, and then which databases are used by which applications, and finally the names, numbers, and email groups of the business users that are affected by that server/database failure.  This will enable your team to proactively manage your customers expectations.  You can notify them before they have to notify you.

3. Become a Quick-Reaction Force:

The SWAT team, the FireStation, and the Ambulance services all have something in common: they are ready to take action at a moment’s notice.

They have the information they need available to them, and additional services available with a simple call.

Do your products have support information organized and readily available?  Do you have the names and numbers of your account representative for each third-party product or tool you support?  Do you have the product-support phone numbers and your support plan credentials readily available?

Do you know who knows what about each application in your enterprise?  Who programmed it originally?  Who has supported it lately?  Which business units use it?  Where is the source code located?

Keeping information about each system updated in a central location should also be part of your “fleet plan.”

Another effective tool for a Quick-Response group is a monitoring system.  Something that indicates the overall attitude of each of your production servers?  Disk Space available? Will the system reply to a ping?  Is SQL Agent running? Is that required Windows Service up and running?  Monitoring tools like Nagios can do this for you.

Another great idea is to keep a lessons-learned log for each component you support.  Track problems, fixes to problems, assumptions to be confirmed, and ways to test if the component is functioning properly.

All of these pieces in place will make your production support much more effective.

So, think about it…is your Software Production Support team playing racquetball, or are they just hitting a ball around a room?

Mike J. Berry
www.RedRockResearch.com

Why you should stop using SQL Server 2000+ (even though it’s a superior product!)

SQL Server 2005 is fantastic.  SQL Server 2000 was wonderful.  SQL Server 7 was OK.  I hear SQL Server 2008 will be even better…

…but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives?

Don’t get me wrong.  I’ve grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name.

Because SQL Server (and Oracle) are highly visible in the public’s radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier.

So my client is spending $500,000 and seven or eight months upgrading their core product–and all of the internal support tools that must work with it–to SQL 2005.  Again why?  To ‘add value to the customer experience’…meaning that the salesperson can say “yes, it works with SQL 2005.”

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for ‘clues’ of what should separate an inferior product from a superior product, and–well–version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer’s radar.  This way, they would have no ‘journal information’ about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft.

PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn’t affect you, but if you make a commercial client-server product, there’s no doubt you’ve experienced this already.

Mike J Berry
www.RedRockResearch.com