Specialization vs. Generalization

Have you ever seen Gordon Ramsey in action?  Not on his Fox Network show, but on his original show, Ramsey's Kitchen Nightmare?  (The Fox Network version is staged and edited to be as confrontational as possible.)  He tries to help a restaurant that is on the verge of closing down and does his best to change things around in a week.  To be honest, there's not a lot that can be done in a week, so if the basics aren't there then there is going to be trouble.

One of the key things that he stresses, however, is to keep the menu simple and to specialize in something.  In some respects this goes completely against the grain of what students are being taught in school and what our supervisors are busy telling us.  IT people are thought of as being replaceable cogs in "the machine", not to specialize, but to be replaceable.  To be honest, IT staff foster this perception as it makes it easier to sell their services internally within an organization and to external organizations, if they so wish.

In a previous life, when I worked for a "large, multinational consulting firm" it was not considered a good thing to be different than everyone else.  Because the types of problems faced by a large consulting firm are quite varied, having a large pool of generalists made it easy for the company to assign people to a project, after all, it's just a different type of nail and they have a lot of hammers (Bernard Baruch).  The more hammers they had the easier it was to sell services to a client.  If a special hammer was needed there was usually a small group (less than 1,500 people in a 65,000 person organization) who had more specialized skills and could be brought in (at a premium of course) to assist the project.

Is this the right way to do it?  Should most people be generalists with a few specialists who could be parachuted in when needed?

Personally, I believe this depends on the aspirations of the people you are dealing with.  In the consulting firm mentioned previously, the vast (90%+) majority of the people were on the fast track to management:  "up or out".  This meant that their time as a developer/designer was limited and that there was no need/desire to become proficient in one particular area of expertise, unless it was a business area.  For these individuals the generalist appellation is more than sufficient.  Some people, however, like the technology.  They like being able to make the computer do their bidding. This group of people is more likely to follow a more specialist perspective and become "experts" in this area.

Before labeling someone either a generalist or a specialist, find out what their aspirations are, then, when assigning new work, take these factors into account when determining who works on which project.  In some cases it may make more sense to assign a less experienced specialist to a project than a more experienced generalist as the final solution may be more effective at resolving the clients issues and isn't that what it's all about?

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.

Post Mortem, but before Death

Justice Gray sent me an interesting note the other day in which he described a "post mortem" debriefing, but before the project had even started.  As Justice put it:  “It’s six months/a year/etc. from now and the project has failed.  Why did it fail?”

One of the things that people have a hard time doing is learning from their mistakes.  George Santayana said "Those who do not learn from history are doomed to repeat it" and that is very true in the IT industry.  We work on projects that are months long, sometimes years, and during each project we make mistakes, fix them and go on to another mistake.  By the end of the project we have discovered, and fixed, dozens of mistakes.  We then make the biggest mistake of all, however, and repeat those mistakes on the very next project.  We failed to learn from our mistakes.

By setting up a post mortem before the project even starts, however, you're asking the developers to think about the project, think about what has gone wrong on previous projects and apply those lessons to the new project.  In essence we are learning from our mistakes and applying the fixes to the next project. 

Does this work?  Well, from my personal experience I've had mixed results.  We did this for a couple of smaller projects and we were quite successful at identifying potential problems early on and work on risk mitigation for those items.  And that is what we are talking about:  risk mitigation.  Identifying a potential problem and what can be done early on to minimize the odds of it happening.  We also tried this same approach on a much bigger project, but the whole process blew up in our faces.  We identified so many potential problems that we spent more time mitigating risk than we did building an application.  And even after all of that advance preparation, we were hit with some nasty problems that derailed the project because of a couple of people who were not committed to the process.

Can this work, discussing potential failures before the project starts?  Most definitely, but it is really important that people think about past mistakes and problems and how to mitigate the risk of them occurring.  It also depends on the commitment of the people involved.  If the people aren't committed to the process then the results may not be what you expect, or need.

Optimization -- Part 3

There's help you can get when you hit the wall for performance?

You bet your sweet bippy there is.  The most obvious places to look for help are with the people around you.  I find that one of the most effective resources I have is my wife.  Now, my wife is not particularly computer literate.  Seriously.  She is, however, an excellent sounding board.  When I explain something to her I have to get rid of the technical jargon and explain it to her in simple terms.  Usually, while in the process of trying to simplify the explanation, my mind goes off on a 90 degree tangent and i solve the problem that I am working on.  This doesn't mean that this will work for everyone, but it works for me.

Or, try reaching out to other designers and asking for their opinion.  Give them a high level overview of the problem, what you've been looking at and let them think for a few minutes.  Don't expect an instant answer, because if something has been troubling you for a while, don't expect someone else to solve the puzzle instantly.  (Although, my wife does really well on those little puzzles where you have to take rings off a rope and untangle hopelessly tangled messes of metal.)

You can even talk to the Deployment Team.  Yes, I know, normally you avoid that, but you'd be surprised at how much help we can be.  By deploying and supporting over 80 applications the odds are that we've seen your problem before and that there are at least two, if not seventeen different ways to resolve the problem and make your life much easier.

Sometimes the answer is really obvious, but because you are so deeply involved you "can't see the forest for the trees".  This is where reaching out to others, both technically adept and technically inept, can help.  It forces you to look at the big picture, the forest, and see whether or not there is a different path.

Secret Meeting

I got my hands on a recording of a secret meeting held between project managers last Friday.  Here it is in it's gory glory.

"OK, so it's agreed, we increase all of our estimates by 10% and blame it on the overhead caused by the Deployment Team.  Right?"

"Ah, hang on a moment.  There might be a problem with that."

"What is it <too garbled to understand>?  What don't you understand about pinning the blame on the Deployment Team?  In particular that pain in the butt, Don."

"Well, don't you think that he might notice what's going on if everyone suddenly complains about his team costing the organization a lot of money?  I mean, I don't think he's a complete moron and he might figure something out."

<sound of people spitting out their beer on to the floor>

"Not again?!?!?"  <sounds like the waitress bring a mop to clean things up>

"What makes you think Jessop can figure this out?"

"Well, he has been in projects before, from a project plan creation perspective and he understands that estimates need to be complete.  And this means that they have to take into account all of the costs of the project.  Some of those costs include interacting with the Deployment Team to ensure that the application is deployed properly."

<long silence>

"You're a plant, aren't you?  You're not really a project manager, your a mole!  Get HIM!!!!"

The recording breaks up at this point as the noise of chairs being tipped over and beer steins breaking on the floor seem to take up much of the remainder of the recording.  There is the faint sound of someone shouting " ... no blood inside the bar ... ", but that could be just my imagination.

So, Project Managers, how are those estimates coming along?

NaNoWriMo

When I started the National Novel Writing Month contest I wasn't sure what to expect.  After all, I didn't have a story in mind, no plot had immediately come forth pleading that it needed to be written, and most importantly, I didn't have the foggiest idea if I could do it.

Well, I am a ways into it now and I must say that the pep talks they gave on the site were correct:  the story does have a tendency of writing itself.  With only the opening sentence to work with the story slowly started to evolve and grow.  Characters started coming together, pasts started being revealed and the tone of the story started to come out.  (Now if only I could figure out some way of making these notes count towards my word total.)

It was really strange because, in many ways, that's how I've always done my programming as well.  To be honest, I was never one for getting all of the requirements together before building the application.  I would start with the framework and start building the rest of the application in pieces.  Sometimes this caused me no end of trouble because I had built the framework in such a manner as to cause endless rewrites due to a specific requirement.  I learned, however, and I developed better frameworks.  I learned to "steal" code from the best of the applications and re-use it where necessary.  In essence, I started with the barest of bones and built up the application in stages, much like what is happening with the novel.

Some might call it eXtreme Programming, while others might just lump it in with the generic term Agile Development.  All I can say is that it worked for me.  It does not work for everyone.  Indeed, the vast majority of people cannot do it this way because of the unknowns and the, to be honest, the fear of failure.  I've failed at so many things in my life that failing at writing a computer program, something I love doing, just never crossed my mind.

Managers and team leads need to understand that there is not just one type of developer.  You can't go to the store and pick up a box of Generic Developers (now with Vitamin B12) and have them substitute for your Toasty O Developers,  Supervisors, leaders of people, need to understand that there is a wide range of people and that some people, very few, can be left on their own to build the application.  Indeed, interfering with that development process is sometimes more harmful than letting them run loose.

Does this mean that you have an entire team of highly motivated, highly charged, highly independent developers at your disposal?  No, you don't.  The key is finding those that are and nurturing their growth.  Studies have been done with regard to programmer productivity, and anecdotal evidence abounds with stories of Software Heroes.  Suffice to say that they are relatively rare, so the odds of finding more than one or two on your staff is unlikely.  Which in some ways is a relief.

 

P.S.  For those that want to know, the opening sentence is:

“The screaming didn’t start when the lights went out; it only started when the first body hit the floor.”