Cancelling a Project

Inertia.  Newton described as a body at rest tends to stay at rest and a body in motion tends to stay in motion, unless acted upon by an outside source.  OK, he actually said:

Corpus omne perseverare in statu suo quiescendi vel movendi uniformiter in directum, nisi quatenus a viribus impressis cogitur statum illum mutare.

But seeing as I don't understand Latin very well I thought I would translate for you.  You're welcome.

"Well, that's all very fascinating, but what does this have to do with IT?"  Glad you asked.  You see, a project is much like a body in motion:  it tends to stay in motion.  Regardless of whether or not the project is required anymore or even if the target has completely changed, the project still moves forward.  There are a few skeletons of this sort in my closet, that I almost ashamed to mention.  (Almost, but not quite.)

Have you ever worked on a project that was headed nowhere and doing it at a break neck speed?  Imagine a project where you're almost finished the design and the technology hasn't even been chosen yet.  Tough to finish your design, isn't it?  Image a project where business rules are changing, but the design of the project is two versions of rules behind.  Not going to be that successful is it?  Imagine a project where the developers are asked to work overtime.  For free.  And then tell them they need to work more over time because the project is behind.  Imagine a project where the Project Manger gets promoted, and removed from the project, and yet his line managers are punished for the current status of the project.  Imagine a project where the "technical guru" is unable to comprehend basic technology, yet insists that his technology choices are sound.  Now imagine him in charge of the overall project!!!!

All of these are reasons for a project to stop.  All of these are reasons for a re-assessment of the viability of the project.

But the project kept going.

Inertia kept the project going.  Inertia fuelled by pride and a stubborn reluctance to say "I think we need to stop".  There is no shame in stopping a project if it's headed in the wrong direction.  There is no shame in saying "Things have changed since we started, let's stop and re-evaluate things before we go too far".  The objective for any project should be for the benefit of the organization.  Sometimes it is better for the organization to stop a project and walk away then it is to let the project continue.  Understanding the long term results of proceeding is more important than finishing the project.

(By the way, the project I was referring to was with a previous employer and should not be confused with any current or previous project of Alberta Education, Alberta Advanced Education & Technology or Alberta Learning.)

Some things should not be "added on"

When building an application there are some things that can be added on afterwards:  new functionality, better graphics and friendlier messages.  These are all things that add more value to the application.

There are some things, however, that should not be added on afterwards:

• Error Handling.  What?  Don't add on error handling afterwards?  No.  It needs to be done at the start.  Now, I know what some of you are saying "But, Don, we'll add this in if we have a problem."  Face it, every new application has problems and if you don't have error handling in at the beginning you are spending needless cycles trying to debug the application and you are causing me to drink Pepto-Bismol as if it were Dr. Pepper.  We recently had to help a project debug their application in the UAT environment, but they had no error handling at all, except the default ASP.NET error handling.  Thank goodness for Avicode, as it helped us pinpoint the problem quickly, just far too late in the development cycle.
• Object Cleanup.  If you create an object, kill the object.  It's simple.  It's so simple that even Project Managers can do it.  By not cleaning up after yourself you raise the potential for memory leaks to happen.  And you know what that means?  Alka-Seltzer, Petpo's cousin. I can't tell you the number of applications in which we recycle the component once it hits a certain limit because it would keep you awake at night.  (Lunesta, another cousin)  Suffice to say that many of our applications are forced to recycle after a certain period of time or when they exceed a certain size. 

The scary thing is that both of these items are considered  best practices for writing code in the first place.  I know the excuses "...the project manager won't let me do this ..." or "...I don't have enough budget to do this ..." or, the one heard most frequently "... I don't have the time to do this ...:.  Very few project managers tell their staff how to code, so the first excuse is just a cop out.  As for the budget, doing these items does not add significantly to the cost of application as it usually makes debugging faster and easier, so the budget excuse is just that, an excuse.  As for the time, if you're short on time, you need to do this as it will help you.

One of the things that many Health Organizations are putting in place is prevention of disease so that there is no need to cure the disease.  Prevention is much more cost effective.  Object Cleanup is prevention, pure and simple.  When someone has symptoms that need to be diagnosed, what does the doctor do?  Perform a seance?  Guess?  Or do they use a tool to help them out?  Ever heard of an MRI or even an X-Ray?  Think of Error Handling as a tool to help you diagnose the disease faster.  It's better than guessing.

So, object cleanup prevents problems and error handling helps diagnose problems.  So, I guess this means that I'll be seeing more applications with these items as an integral part of the overall application or do I need to go back to the medicine cabinet?

Work Smarter, not Harder

Raise your hand if you have had someone tell you to "work smarter, not harder"?  Ah, I see the majority of hands in the air.  (Careful about that.  People might think it strange for you to raise your hand in response to a line in an email.  I won't tell anyone though.)  So, how do you work smarter, not harder?  (i.e. increase productivity)  Yes, in the following paragraphs I am going to give you an entire book's worth of advice, so pay attention, this is pure gold!

The premise behind "smarter not harder" is that you only spend time on the most important things and leave the "back burner" stuff until there is time to do it.

There, that's it.  That'll be $19.95 CDN please.  Only PayPal at the moment.

Wow, that was most ... unsatisfying.  But, you know what, I think I've saved a lot of you $19.95.  Let's face it, there is no silver bullet for dramatically increasing productivity.  No magic spell is going to dramatically make you more productive.  Nothing you can do right now is going to have a significant impact on improving your productivity in the next couple of weeks, right when your supervisor wants it most.  You can read books, attend seminars, hire personal development coaches or a myriad of other things, but the truth is that change takes time.  if you type 30 words a minute, you aren't going to suddenly start typing 60 words a minute because your supervisor said you should.  If you can run a six minute mile, you aren't going to get down to a five minute mile just because a book told you that you could.

All of these things, including "smarter not harder" require practice.  A book might tell you what you need to practice.  A seminar might guide you in the right direction for general areas of improvement and a personal development coach might lay out a detailed plan, but the reality is that it all depends on you.  Without the practice, the commitment and the desire to work smarter, it isn't going to happen.  But even if all of these things are in place, it is going to take time.

So, where does this leave all of the people telling others to work "smarter, not harder"?  Well, the odds are that they are in a supervisory position.  The odds are also in my favour that this person is experiencing a time crunch whereby the amount of work has now exceeded the capacity of the staff.  So, in an effort to increase the capacity of the staff they are asked to work smarter.  This may or may not be used in conjunction with greed ("we'll give you a bonus if it's done on time"), fear ("we'll can you if it's not done on time"), heroism ("everyone is depending on you to save their butts") or, as I've seen in one instance, all three approaches.

Essentially, if you are at the point where you are telling people to work "smarter, not harder", you've already lost.  Suck it up, realistically plan the project and change either the target date (sometimes), the scope (sometimes) or add more people (dangerous as this will also increase the effort required).  If you really want people to work smarter, then help them at the beginning of the project, not when there is a crisis.  Help them plan their work.  Help them organize their InBox.  Help them become better developers prior  to you needing them to become better developers.

The Dark Side of Objects

The Dark Side of Objects?  (Luke, I am your father.) 

Sometimes you need reins on developers and designers.  Not because they aren't doing a good job, but because if you don't you may end up in a quagmire of objects that no one can understand. Objects are good, but they can be overdone.  Not everything should be an object and not everything lends itself to being objectified.  Sometimes a developers goes too deep when trying to create objects.

When I was learning about objects I had a great mentor who understood the real world boundaries of objects:  when to use them, how to use them and far to decompose them into additional objects.  Shortly after having "seen the light" with regard to objects I was helping a young man (okay, at my age everyone is young) write an application which was actually the sequel to the data entry application I mentioned in the previous note.  He needed to do some funky calculations so he created his own numeric objects.  Instead of using the built in Integer types he decided that he would create his own Number object.  This number object would have a collection of digits  When any calculations needed to be done he would tell one of the digits the operation to be performed and let that digit tell the other digits what to do.  Well, this gave him a method whereby he could perform any simple numeric operation (+-/*) on a number with a precision of his own choosing.  He spent weeks on perfecting this so that his number scheme could handle integers and floating point numbers of any size.  It was truly a work of art. 

And weeks of wasted time.

What he needed to do was multiple two numbers together or add up a series of numbers.  Nothing ever went beyond two decimal points of precision and no amount was greater than one million.  These are all functions built into the darn language and didn't need to be enhanced or made better.  The developer got carried away with objects and objectified everything when it didn't or in this case, shouldn't have been done.

Knowing when to stop using objects is just as important as knowing when to use objects.

Solving the Right Problem

One of the hardest things to do it solve the right problem at the right time. 

When investigating a problem you may end up looking at a wide variety of possible solutions.  Some of these solutions are quick fixes while others require a fair amount of effort to implement.  The question is, which one do you propose?

For a crisis, the quick fix is usually the right choice.  Things need to be resolved quickly and the best solution may not be able to solve the problem fast enough.  As a result the quick fix is usually chosen for Production emergencies and rushed through into Production.  Quick fixes are not meant to be permanent solutions, but in many cases they end up being permanent for a variety of reasons.

In less crisis oriented situations, however, the best solution may actually be the resolution of a deeper, more convoluted problem that is actually the root cause of the issue.  Unfortunately, resolving the root cause of a problem may actually be a problem in and of itself.  There may be significant effort and money that needs to be spent in order to resolve the issue in the manner that it should.  Sometimes the problem is so fundamental to the application that it almost appears that you have to re-write the application to make it work as desired.  If this is the case, is this what you should propose?

As with many things in life, it comes down to a business case:  is the cost of implementing the solution less than the cost of living with the quick fix?  If this were strictly a matter of dollars and cents then the answer would be know right away.  Unfortunately the cost of living with the problem is not easily quantifiable.  How do you measure consumer lack of confidence in terms of cost?  How do you measure consumer satisfaction in terms of cost?  in many cases only the business area affected can even hope to determine the cost.  It is our job to present the facts as we know them, the costs as we know them, and let the business decide the ultimate cost.

n-Tier environment ... design

One of the biggest differences, at least in terms of perspective, between a Win32 application (aka Fat Client) and a web browser application is that the Win32 application is used by a single person whereas the web application may be used by hundreds, or thousands of people at one time.  OK, quiet down out there, let me explain.

A Win32 application is run on a desktop and is run by a single person at a time.  The application may be installed on hundreds or thousands of machines, but each machine has a single person running the application.  In this manner the workload is distributed between each workstation and the database server.  In a web based application all of that processing needs to occur somewhere.  While some of it happens on the browser, a good portion of it runs on the web server.  Therein lies the problem.

Many web applications are built in such a manner that they consume large amounts of CPU and memory in order to serve a single client.  Multiply by the number of people that are going to be accessing the application and you have a nightmare on your hands. Many years ago servers used to be much more powerful than desktops.  This was due to the advance architecture used in the servers and the very expensive chips used.  As prices have dropped, however, this distinction has almost completely disappeared.  Indeed, a new desktop may, in some circumstances, be faster than the server to which it is communicating.  Because the average developer has a fairly powerful machine, what seems to run quickly on their desktop completely bogs down on the server when multiple people try to access it.

Our current Production servers are quite large and contain a lot of raw horsepower.  We do not have a large number of concurrent users.  I would personally be surprised if we hit 40 on any one server.  This is in comparison to a server at Google that is designed to support hundreds of concurrent users.  On-line games, such as World of Warcraft, support thousands of concurrent users.  While we don't need to write our applications so that we can support thousands of concurrent users, we should always be cognizant of the fact that our application does not operate alone.  It needs to co-exist with itself and others.

Batch Processing ... Part Two

I must be honest, I am sometimes quite surprised by the reaction my notes some times invoke.  For instance, the note about batch processing generated a number of "high fives" in the hallway and a couple of 500 word responses.  The response was, as I expected, all over the place with some people telling me I was not in my right mind while other people were saying that this is what they have always believed.  Never one to let the flames of disagreement burn out, I thought I would list my personal rules as to whether or not something should be done in batch.  This is not something you need to follow, but it may help illuminate my comments from the other day.

Interfaces with other systems.  I originally had the word "external" but I replaced it with "other" as different systems internal to an overall application may not be able to handle a continuous stream of data.  For instance, our interface to IMAGIS is done through a file transfer which is done once a day.  To ensure that we get as much as possible into the system we do the transfer close to the cut off time that we have arranged with the IMAGIS team.  In this case the target system is just not designed to handle us sending them information multiple times per day.  Now, it may be the case that there are other ways to communicate with IMAGIS that we have not utilized, but with the current set up, we need to do it on a scheduled, batch basis.

Reports. This seems like a logical item to do in a batch process.  Whether this batch process is done via another tool, such as ReportNet scheduling the report, or whether it is scheduled via Windows Scheduler, reports are good batch residents. However, in my mind a report does not process and create data, it merely reports on the data.  If your "report" creates and stores data then that portion should be separated out and done in an asynchronous manner.  A report, any report, should be able to be generated quickly from data that is already stored in the database.  In addition, in many cases, reports do not need to be run on a scheduled basis, as long as the report can be generated on demand and that it will contain the identical content as if it had been generated on a previous day.  For instance, if reporting on the applications that were approved on July 12th, it would list all approvals, even if one of the application was subsequently denied.

And that's pretty much it.  It's a very short list of things that need to be done in a batch window.  For me it all comes down to this:

It is our job as IT Professionals, however, to not just do what our clients say, but to educate them as to what can be done, to show them new opportunities, and to give them something better than what they had, not just something newer.

The n-Tier world .. hardware

Does an n-tier hardware environment actually make things better?  I was asked this question recently and, to be honest, it made me pause and reflect on the promises of the n-tier world versus the reality of an n-tier world.

The n-tier push really started gaining hold, again, in the 90's when the Internet was young and foolish and so was Al Gore.  As a result, most people associate the idea of an n-tier environment as one that is web browser based.  While this is not always the case, the majority of applications currently being developed are web based, so we will run with that and assume, for the purposes of this discussion, that our n-tier environment consists of a web browser communicating with a web server that in turn communicates with a database server.

With regard to the web browser, the idea was that with a "light" front end that was downloaded every time you requested it you did not need as much processing power on the desktop (Internet Computer anyone?) and you could make changes to the application without having to distribute an application to hundreds, thousands or even millions of customers.  This has proven to be a valuable and worthwhile objective of browser based deployments and allows for quicker changes with less client impact.

Separating the main logic on to a web server or cluster of web servers (see previous notes about this) then allows the developer to change the application and only have to do it in a limited number of locations.  While this has allowed the developer to deploy applications quickly, the problem here lies in the fact that the developer(s) build the application as if it was the only thing running on the server, when in reality it is usually one of many applications.  Resource contention (memory, CPU) usually mean that going to a cluster of servers is a requirement.  It is also a common misconception that adding more servers will make the application run faster.  Adding more servers allows you to support more simultaneous users, but does not necessarily make the application run faster.  As a result, a poorly performing application will perform just as poorly one machine as on a cluster of 20, although you can annoy more people on cluster.

By placing all of the database access on a machine, or cluster of machines, there are fewer connections to the database that need to be monitored and managed on the database server.  This reduces memory usage, CPU usage and allows the database to concentrate on serving data to clients.  Unfortunately, this is the where one of the biggest problems is in the n-tier world.  Developers need to optimize their code when accessing the database.  Whether it is reducing locks and deadlocks, reducing transaction length or simply designing better applications and databases, the database back end, regardless of whether it is an Intel box, a Unix server or an OS/390 behemoth can only handle so much work.  Web servers can be clustered, but in order to get more than one database server to service requests against the same data you need to have a much more sophisticated and much more complicated environment.  Just adding another server won't cut it as the database server is constrained in terms of the memory and CPU we can use.

So, has n-tier lived up to it's promise?  Sort of.  The web browser side:  yes.  The web/application server side:  mostly.  The database side:  not as much as expected.  The problem is not the technology, rather the people.  We have created an infrastructure that can do great things.  What we need to do now is teach people how to create great things with that infrastructure.

Hot Fixes

What is a hot fix?  This question seems to be coming up  more often and I think it needs a bit of discussion in this arena.  Definitions of hot fix that I have seen include:

• A hotfix is code (sometimes called a patch) that fixes a bug in a product. (Source)


• Microsoft's term for a bug fix, which is accomplished by replacing one or more existing files (typically DLLs) in the operating system or application with revised versions. (Source)

I think we can all agree that a hot fix is something that fixes a bug.  The question now arises as to the size of the patch.  The second definition is important in this aspect as it talks about replacing one or more DLLs.  So, a hot fix will fix a bug by replacing an indeterminate number of DLLs.  Darn it, I've used that word again: replacing.  That happens to be the crux of the problem that we are experiencing.

Replacing DLLs does not mean the uninstaling of the entire application and the installation of a new version of the application which has the bug fix inside.  This is simply an install of the application.  A hot fix would take the DLLs that were changed, package those up and install those on affected machines.  This is standard practice used by Microsoft, IBM, Sun, Oracle, Hewlett Packard, PeopleSoft, SAP, Symantec, Trend Micro, Adobe, Electronic Arts, Intuit, AutoDesk Check Point, and, quite literally, millions of other companies.  You don't re-install Windows every time there is a hot fix for Windows.  You don't re-install your anti-virus software every time there is an update to the software.  You don't re-install your entire application because there is a spelling mistake on a page.

If you are asking for a migration to a Shared Environment, and you are essentially asking us to install a new version of the application, don't call it a hot fix, as you are disagreeing with the vast majority of the IT world and the definition that the Deployment Team uses for a hot fix.  A hot fix replaces DLLs.  By packing everything up into a new install for the application you are potentially including other changes in your fix that are not related to the bug you are trying to install.

Deadlocks ... Part 1

Deadlocks are an interesting condition within the database.  In very simplistic terms, it occurs when two people are both trying to change data that the other person has already changed.  For instance, Person A has already updated Row 1 in Table 1 and now wants to update Row 2 in Table 2.  However, Person B has already updated Row 2 in Table 2 and is trying to update Row 1 in Table 1.  As you can see, unless someone gives in they could sit there all day.  The database is the arbiter in this case and makes a decision as to which person is going to get the error message when their transaction is canceled.

Now, you may have heard the phrase "Deadlocks are a natural part of application processing and are not a large concern."  While I do not advocate violence, the person who says this should be slapped in order to knock some sense into them.  Deadlocks are not a natural par tof an application.  I previously worked on a web-based system that had, as regularly peaked at over 650 simultaneous users, with over 250 of those being "hard core" users. This is 10 times the size of any application we have currently running.  If we got a single deadlock during the day we had to investigate why the deadlock occurred and determine if the deadlock could be prevented.  We would go for weeks, or even months without a deadlock, but when one occurred we dropped everything and investigated the problem.

Why do we get deadlocks in an application?  Sometimes it is because in one part of an application we update Table 1 and then Table 2, but in other parts we update Table 2 and then Table 1.  This is a disaster waiting to happen.  In other circumstances we have background tasks running that are not properly tuned and they try to update too much at once before committing their data.  This is also another disaster.

There are a number of surprisingly simple and, to most people, obvious strategies to use that will eliminate deadlocks to the "rare" occurrence that they should be.  We'll discuss those tomorrow.

Interim

Interim is an interesting word.  When people look at the word and use it, they might actually have a different opinion as to what the word means.  For instance, they may say that something is "an interim solution".  Based upon how most people in the IT world use the word they would assume that the solution is a short-term solution and that something is coming to replace it.  They would be wrong, in more ways that one.

Strictly speaking, the definition of interim is something like this:

... the period of time between one event and another ...

Not very specific is it?  According to the definition, an interim solution would be a solution that is in place prior to the final solution being installed.  IT people, however, haven't really been using the word in quite this manner, or rather, they have been hoping the word is not used in this manner.  They honestly believe that the phrase "short term" is in the definition.  Sorry, but it isn't there.

What this means is that if you specify an "interim solution", you had better be comfortable with that solution because there is no time limit on how long that solution will be in place.  If you are not comfortable with the solution as a long-term solution, do not promote it because many interim solutions have become long term solutions, regardless of how much we dream and pray.

Everything New is Old Again

You've just rewritten your application using the next version of the development tool and your web app is up to date with all sorts of spiffy new features.  Your team is tired after the prolonged effort to get things running, but it's done and you can relax.

Unfortunately, with today's technology, you've also signed up for a continual cycle of redevelopment and maintenance.  I can hear the mainframe guys saying "Oh, we never have to do that."  Yeah, right.  The longest weekend of my life (well, maybe the second longest) was spent compiling over 1900 COBOL programs, four times, once for each of our different environments (DEVL, SYST, UAT, PROD), all because the version of COBOL changed and made certain programming approaches invalid with the new version of COBOL.

Technology changes, of this there is no doubt.  Businesses that produce that technology will only supply support for a specific period of time.  They need to continually make money to fend off shareholders and supporting old technology is a money sink, not a money generator.   Within Microsoft there is something called Mainstream Support and this is the period when hot fixes are free.  Hot Fixes are available in Extended Support, but only if a support agreement is paid for in advance.  For some Microsoft technologies that we currently use these are some dates for the end of Mainstream support:

• .NET Framework 1.1 - October 14, 2008


• Visual Basic 6 - March 31, 2005


• Visual Studio 2003 - October 14, 2008


• SQL Server 2000 - April 8, 2008


• BizTalk 2002 - July 10, 2007


• BizTalk 2004 - July 14, 2009


• Windows 2000 - June 30, 2005

Take a look at the list and you'll see that for many of your applications, Mainstream Supports end within the next 18 months.  While this may not be an issue for some of you, you should consider upgrading the development tool as failure to do so may result in incompatibilities between your application and newer technologies.

Batch Processing

Batch processing is the mainstay of mainframe processing. This is where you get to line up one, two, dozens of jobs, let them take off and then charge the various departments, divisions, companies, based on the CPU time used for that job. People would schedule their jobs for weird hours of the day because you normally got charged a lower rate for processing at night or during "off peak" processing hours. After all, the mainframe was only a certain size and you had to ensure that your online customers during the day had the processing power available to them for what they needed done.

In the Wintel (Windows/Intel) era, however, batch processing is, quite frankly, antiquated. There are few tasks that actually need to be done in a batch manner as many of them can be done in an asynchronous manner throughout the day. Now, I am not including reporting in this as some reporting needs to be done on a consistent, daily basis and can easily be scheduled (if the report even needs to be run at all!). What I am referring to is setting up Job B to run only after Job A has successfully completed.

To be honest, in 90%+ of the cases there is no good business reason why Job B must run after Job A. What there is a specific business reason for is business process B to follow business process A, for a specific, small set of data. In one of my previous lives I worked in the insurance business. You didn't pay out on the insurance until you determined the persons eligibility. You did not need to determine the eligibility of everyone who applied that day before paying a specific person, you just needed to determine the eligibility of that one person.

This is a completely different mindset than what many "old timers" are used to as we are no longer concerned about trying to schedule things for "off hours". Instead, we are processing the data on an as-needed basis. What does this do? Well, in many cases it eliminates many batch jobs as the majority of the processing has already occurred during the day. It eliminates the need for fancy scheduling between jobs. It eliminates the requirement for a batch window.

This isn't an easy mindset to get rid of. Many customers still operate in this mode as it is easier to understand and is much more familiar territory. It is our job as IT Professionals, however, to not just do what our clients say, but to educate them as to what can be done, to show them new opportunities, and to give them something better than what they had, not just something newer.

Microwaves and IT

I was trying to follow the instructions on the back of the box the other day when I cam to a part that had me stumped.  It said that in order to defrost the item I held in my hands I needed to set the power to low and put it in the microwave for 2 1/2 minutes.  Now, I consider myself to be reasonably intelligent (some may not agree with that statement) and I consider myself to be somewhat of a technology geek.  I like silly, geeky things, but, darn it, I can't defrost anything in our microwave!!!!

Now, thinking just like the instructions, I set the power to low and then tried to enter a time, but for some reason I was entering in the time for "Step 2" of the overall process instead of Step 1.  So, I hit the "Defrost" button and was asked to enter in the weight of the object in kilograms.  Tossing it up and down like the frozen pork sandwich from Costco that it was, I guessed at about 0.1 KG.  I tossed it in the microwave and crossed my fingers.  I came close but it was probably about 0.15 KG, which I couldn't enter as it expected only a single digit after the decimal point.  (By the way, the correct method was to enter in the time, then enter in the power setting.  I had this epiphany on the bus on the way to work this morning.)

We sometimes build applications the same way that manufacturers build their interfaces.  it makes perfect sense to one or two people, or even the "study group" that looked at the interface, but when you give it to someone that has never seen it before, has never been part of the privileged few that saw the development process, the interface sucks.  Sorry for the bad news, but interfaces made by geeks are ... well, geeky.  They make sense to geeks, some of them,  but honestly don't make sense to anyone else. 

You see this in many applications and still see it today.  I was looking for an application to catalog by DVD collection using information sucked out of the Amazon.com database.  I found half a dozen applications, but they all looked like they were put together by Picasso.  I then found an application that looked like it was put together very well.  They had the complete package from the functionality that I wanted to a simple, pleasing user interface.

Project Managers, don't trust developers when it comes to user interfaces.  Look at the designs yourself and see if they make sense.  if you can't figure out how to do something, get it redone as someone totally unfamiliar with the project is going to be completely lost.  If the response is "the user wants it this way" then this really means that there are too many geeks trying to cook and it might be time to bring in a professional designer to help you out.

A World of Difference

There is a world of difference between maintenance and development projects.  NOT!!!!

OK, this may be a controversial topic, or it may not be, but I think I need to put some parameters around my comment.  In my mind, the actual act of developing a new application, doing a major enhancement to an existing application, doing a minor enhancement to an existing application or doing a bug fix for an existing application are fundamentally the same with regard to the tasks that need to be accomplished.  How the organization wishes to perceive them, from an accounting, management or accountability perspective may be different, but the same process need to be accomplished.

Whether the scale of the work is large (project) or small (bug fix), the developer still needs to have some requirements, do some coding, do some testing (really important step) and promote it to the next environment.  How the Project Manager (remember this isn't necessarily a title, but a role that someone plays) organizes these tasks, reports on these tasks and celebrates the successes with the team (you do this, right?) is up to the Project Manager.

Some organizations have an arbitrary limit of xx days of effort means a project.  Or perhaps there is an accounting limit of $yyy,yyy dollars is operating (maintenance) but anything over is capital and needs to be a project.  But you know what?  If it takes xx-1 days or xx+1 days, from a developers perspective there is no difference.  If it takes 19 days (maintenance) to add a feature to an existing application or 21 days (small project) to add that exact same feature, the developer is doing the same work.  The processes that the organization asks for may be different, the documentation requested may be different, or perhaps it is who pays the bill that is different, these are all things that surround the core act of development, but should not impact it.

If you feel that I am wrong, please let me know, although based on previous notes I don't think anyone reading this has any qualms about letting me know that they disagree with what I am saying.

Failure

Being old, excuse me, older, than many of you gives me an advantage over you in a number of ways. I will be able to get the senior rate at the movies before you and I will be able to get discounts at hotels before you. What it has also done, is given me the opportunity to fail more often than you.

One of the best teachers in the world is failure, as it shows you what went wrong and what not to do. All you need to do now is learn from that failure and try to prevent that same situation from happening again. As someone who has been in this field for 20 years I have experienced a lot of failures, both on my part and those with whom I’ve worked. Each failure has been a learning experience that has allowed me to gain some piece of knowledge such that I am able to either not fail in the same manner or at least recover faster.

Unfortunately, failure is often seen as a bad thing, and from an overall project perspective it most certainly is a bad thing. However, small individual failures are not something that should be frowned upon, but embraced. Scott Berkun, in The Art of Project Management, wrote:

Courageous decision makers will tend to fail visibly more often than those who always make safe and cautious choices.

This applies to everyone that makes decisions, from the project manager down to the developer. If a decision was made that was, at the time, the right decision, celebrate the decision, regardless of whether or not it was a success. If the decision was bad, educate the decision maker so that they can learn from their mistake. (Educate does not mean punish.) By telling people you expect them to be perfect and that you do not expect any problems, you are telling them to play things safe and not try anything new. Mankind didn’t go to the Moon by playing safe. IBM played it safe with the personal computer and lost. Risks need to be taken at certain points and we need to train all of our staff, from developers to project managers, when failure and risk, is a good thing.

Branching Guidance

Sometimes there just isn’t a shortcut to the right answer. You know what I mean: instead of researching the answer yourself, you lean over, talk to your buddy for 30 seconds and he gives you the answer you need. In many cases this works when you’re trying to solve a silly little problem or you just can’t remember the name of the runner up in last years American Idol.

Other problems, unfortunately, require that you understand the background behind the solution before you can actually understand the solution itself. String theory is like this. So are some aspects of quantum mechanics. Most business problems, don’t fall into this level of complexity, although I have seen the odd case where PhDs would be confounded by the sheer complexity of what has been engineered. Not necessarily what was required, just what was engineered.

In some cases there is some simple help, but it does require a bit of reading. I was recently asked for information about when to do branching and exactly how it should be done. In this case, I went to somebody who needs to do this on a frequent basis: Microsoft. Indeed, the information at CodePlex was excellent in terms of it’s understanding of the problem and the potential solutions. For those of you who think you understand how branching should be done, and for those of you who are at a loss, I recommend this document as an excellent source of information from which you can retrieve the bits and pieces that are of particular interest to you. It is not a light read as the amount of information it contains is quite voluminous (approximately 28 pages), but it gives you some interesting insight into an arcane subject.

High Performance Teams

In another life I was busy researching the idea behind "High Performance Teams" (HPT). These teams are not NASCAR fans, nor are they hooked on amphetamines. Instead, they are a group of individuals who work with each other really well and outperform other similar groups in terms of their quality of work and the speed with which the work gets done. You've seen these teams in hockey as the coach will normally put certain players together and keep them together throughout the season with few changes.

In IT, however, the concept of a high performance team does not always seem to be understood or even implemented in many areas. A team can be as small as two people, or it can be much larger, but there are some key traits that all of these teams share. (OK, here is where I differ from conventional wisdom so if you want you can tune out, even though you may be missing some really cool stuff.)

• Trust. Perhaps the most important trait is that the members of the team trust each other to make the right decisions or at least a decision that can be lived with by everyone.


• Communication. Team members communicate with each other effectively. Different people understand things in different ways. Some people like metaphors, others like analogies while others love diagrams. In a HPT the appropriate mechanism is used at the right time to maximize the effectiveness of the communication.


• Commitment. Each team member knows that every other member of the team is just as committed as they are to producing a high quality product.


• Continuous Improvement. An HPT is not satisfied with the status quo, they want to do the next job better than they did the last job and the one before that, by continually improving how things are done.

Some organizations are not ready for HPTs as it means setting a group up as being "special". Others are not interested as they believe, rightly or wrongly, that if people just follow the process everyone would be part of an HPT. Some larger projects do implement this concept within the overall project and find that the HPT is extremely productive and crucial to the success of the project.

It may not be your cup of tea, but at least you're aware of the possibilities.

Planning for Change

People have come up to me recently and expressed a concern that I am losing control of my mental faculties. To emphasize this point they point to the fact that I keep talking about "planning" and yet I am also an advocate of Agile Development. The usual comment I get is "In Agile Development, you don't plan, you just do."

Ah, the misguided conceptions of youth. Contrary to what people believe, Agile Development does believe in planning, but they are not slaves to the planning process. I once worked for a Programme Manager from Chicago who was quite ... stubborn ... with regard to his belief that if it isn't on the project plan you don't do it. Needless to say we butted heads a number of times, with him always coming out on the winning side because he was the Programme Manager.

This caused a few problems with the client and the application, however, as we were never responding quickly enough to requests. Each time something new came up we had to revise the project plan to take this into account and then confer with the client about the correct project variance that this would cause and sign off on the change request. This process took a number of weeks to complete. We were as agile as a beached whale.

After a while, we figured out how to handle the Programme Manager: insert line items into the plan, that planned for change. Indeed, that is what any agile project should do. Yes, you need to have an overall plan as to what you are going to do and when you are going to do it, but you also need to plan for change. You need to understand that change is natural in a project and you should develop your plan, and work out, in advance, how to deal with change with the client.

Change management is just as important to the development of an application as it is to the ongoing maintenance of an application.

Oh, That's Easy -- Part 2

"Oh, that's easy."

As a project manager I hated those words, particularly if they were coming from my technical team. The more technically adept a person is the more inaccurate the person is at coming up with estimates. Yes, there are exceptions, but they are few and far between and should not be counted on at all times.

Someone who is familiar with the technology and lives and breathes the code is someone who is going to be horrible at coming up with estimates for other people. Heck, they are even horrible at coming up with estimates for themselves. I have had the privilege of working with some very talented people over the past 25 years (damn, there's that age thing again) and with the rare exceptional circumstance, every single one of those people has problems with estimates.

So, how do you compensate? First of all you need to ensure that the developer has thought of everything. Most of the time an estimate only includes the raw time to develop the code, but not to test it, document it and ensure that any technological innovations are compatible with the existing environments. You need to keep track of this persons estimates and use previous estimates in guiding your decision about current estimates.

No, don't create the estimate for the developer as you probably don't know the technology. (See yesterday's note.) Understand, however, that the developer is going to be optimistic about his part of the solution so you need to take his estimate, inflate it, and come up with something that is realistic for the project. And, the most important point of all, keep track of previous estimates and how they matched reality. As mutual funds state "Past performance is not an indication of future results", but they're probably darn close.