Let Them Fail

One of the things that we do as parents is let our children fail at things. 

It's hard not to step in and immediately show them the right way, but we let them fail so that they will learn.  When learning to crawl and then walk, we show them what needs to be done, we act like babies ourselves and crawl around on the floor, but we let them figure out for themselves how to move their arms and legs.  When they are older we watch as they try to put a square peg in a round hole.  If we tell them it can't be done, that doesn't sink in as much as having them fail, repeatedly, and for days sometimes, to get that square peg through that hole.

As they get older, they get "smarter" in that they recognize much quicker when something is wrong and they change their actions.  No longer do they spend 10 minutes trying to get two legs in the same pant leg, as they recognize within moments that things are quite right.  After a while, however, their hormones kick in and they become as stubborn as babies with that square peg, because they are "smarter than you" and they "know more" than you did at that age.  Once again, we let them fail, knowing that the phase will pass and that they will learn.  Sometimes painfully, but they will learn what works and what doesn't and the fact that the tattooed, lip-pierced biker down the street might not have the same interests as them.

Finally they become adults, get an education (sometimes) and get a job (hopefully).  And what happens then?  Many organizations punish people who make mistakes or make it so intolerable to function that the person quits.  For the most formative years of our lives we are left to our own devices.  We are allowed to fail, knowing that someone is going to help us out by not necessarily helping us solve the problem for us, but by letting us know that it is safe to fail.  Why does this change when we get a job.

I've made so many mistakes and failed at so many things I can't count.  I recognize some of my biggest failures and I know that I have learned from them.  I recognize some of the repeated failures where I have hit my head against the wall over and over again, only to have something finally sink in.  But the one thing that I also notice is that I have been allowed to fail.  Yes, I have had my knuckles rapped for failing, but it was only when I failed to learn was the subject every really brought up.  I consider myself quite fortunate to have had supervisors who were willing to let me fail at something, so that I would learn, rather than coddling me and telling me exactly what to do. I essentially got on-the-job education from my mistakes.

Looking back on it I realize that the best thing we can do for people is let them fail and then support them as they try again.

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?

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.”

Creative Juices

One of the best things to do, in order to keep the brain alert and creative, is to read different things.  In the same vein, writing is a good therapeutic use of brain cells.  It keeps the neurons working and allows you to be more creative in your job.

To that end, I would like to introduce National Novel Writing Month.  In essence, you are being challenged to create a novel (50,000 words) in less than a month. That's 1500 words per day.  You are considered a "winner" if you actually succeed at getting in 50,000 words.  They don't have to be perfect, you just need to try.

In this case it is definitely the journey which is important, not the final product.  By pushing yourself to reach this goal you are going to be exercising a variety of different areas of your brain.  You will need to be creative to come up with a plot (and subplots), with characters that you empathize with and the words that tie all of this together.

So, how does this help you in the IT field?  I think you would be amazed at how much it will help.  People talk about "thinking outside the box" in order to get something done.  The problem isn't so much thinking outside of the box, it's understanding where the box is in the first place!!!  As you start writing the novel you will be able to see the box that you have created around your novel and this insight, this new vision that you've gained, can help you see the boxes that surround your problems.  Being able to see something is the first step in being able to avoid it or, in this case, think outside of it.

Are you suddenly going to see everything in a new light?  No, but by constantly stretching and pushing your own mind you will see the limitations (the box) that you have put around yourself.

Just Because ...

Just because you can do something, doesn't mean you should.

Geeks like new things.  They like playing with new technology.  Using new tools.  Trying out stuff that they've never done before.  XML is a good example.  XML has a lot of really good useful purposes.  It allows for easier portability of data between disparate systems.  It is, for the most part, human readable.  It is good for configuration files.  Indeed, configuration files are probably one of the most commonly used applications for XML.

There is one thing (okay, probably more, but this topic needs to be short enough to keep your attention) that XML shouldn't be used for:  continuously updated reference tables or codes tables.  For instance, you wouldn't put the conversion rate between U.S. and Canadian dollars into an XML for processing by an application because it would involve daily updates to that file.  You probably wouldn't put the top 10 grossing movies of the week into an XML file either, as that changes quite often as well.  You could, however, put a list of provinces in XML as that normally doesn't change that often.

We have a carefully controlled production environment.  In order for any new files to be moved into Production we first deploy them to UAT, have them tested and then moved into Production.  You can see that by putting volatile data in an XML file you are creating a lot of extra work for you, the Deployment Team and even the users who need to test the changes as every change will create a lot of overhead.

What's the alternative?  A database.  Reference tables that have the potential to be changed on a frequent basis should never be put into XML files, they should be placed into a database with the proper screens in place to change the data.  Putting this sort of data does nothing for your application in terms of flexibility or ease of use.  It was a matter of using a cool new toy when it didn't need to be done.

New Topics

There are two questions that I am always asked with regard to this daily blurb:

• How do you come up with new topics every day?


• How can you write so much about such a small topic?

Getting new topics is easy:  I pay attention to what is happening around me.  Many of the topics discussed are reflections of what is happening in and around the Deployment Team on a daily basis.

As for the content, in many respects it is the same thing that makes everyone better:  practice.  The more you do something the better you get at it.  How do golfers get better?  They practice at the course they are going to play at.  How do writers get better?  They write about a topic, almost any topic.  How do presenters get better?  Join Toastmasters and practice presenting.  How do programmers get better?  Write programs.

While it may not be intuitive, writing programs for developers is a good way for them to get better.  Now, there is a caveat:  the programmer has to want to get better.  Just like all of the other people listed, if you want to improve and you practice at it, you will get better.  Now, this isn't to say that with practice everyone is going to be the Tiger Woods of .NET, but you will improve and that's the objective.  Write programs.  If you want to learn how something works, write a program to test things out. Try to figure out how to do it yourself before relying on books and web sites to tell you.  You are more likely to grow as a developer if you overcome the challenge yourself.

But above all, write.

Striving for "It Doesn't Suck"

While waiting for the bus I looked across the street and noticed that someone seemed to have written a long essay on the plywood surrounding the construction site.  While I couldn't read much of it, what I could read was very thought provoking:

... should we be striving for "it doesn't suck" as our goal?

Is "it doesn't suck" ever something we should strive for? 

As I sat down on the bus, thousands of images flashed through my mind, all of them related to that comment.  For instance, did you know that of the last 24 toy recalls in the United States, every single one has been related to a product that has been shipped from China?  Due to various pressures, both in the Chinese company manufacturing the toy and the American company importing the toy, the people involved probably thought that "it doesn't suck" was a pretty good choice.

It doesn't suck doesn't necessarily mean that something is good, just that it isn't bad.  There is still a wide gap between good and bad and it doesn't suck only covers a small area of that gap.  Now, I will be the first to admit that this problem is not specific to one role within the project.  Everyone, from the project manager to the developer and everyone in between, has to commit to striving for something better.  While one weak link in the chain can have a downward affect on the overall quality of an application, that does not mean that it cannot be remedied.

When I was younger I remember the news talking about the lack of quality of North American products and how products from overseas were better built and cost less money.  Ford started an ad campaign about "Quality is Job 1".  Much has happened since that time.  Overseas products no longer have the same high regard as they used to (at least some overseas products), but the rise in quality in North American products has not been that great.

The sign of a great company, and great staff, is one where no one strives for "it doesn't suck".  The purpose behind all of our work is continual improvement towards something better.  Something good.  Something great.  In my mind, what we should be striving for is "it's awesome".

Not just IT

Cross fertilization.  No, we're not talking about agriculture.  What we are talking about is the ability to look at other areas and bring some of those concepts and ideas into your own area.  Jim Collins talks about this in the PBS show Good to Great when he showed how public sector organizations (for example, a police force) can utilize the tools, experience and lessons from a company such as Starbucks to revitalize and improve themselves  Just because something isn't in your area of expertise, doesn't mean that you can't read it, watch it, enjoy it and, most importantly, learn from it.

For instance, the whole idea behind Design Patterns for IT applications was started by a 1977 book by Christopher Alexander that established a pattern language to discuss the construction of towns and buildings.  It was a book on architecture, not IT.  The idea behind this book is what prompted a number of individuals in the IT field to look at a pattern language for designing applications.

While it is important to understand what is happening in your own field and be proficient at it, there is an alternative need to broaden your perspective and look at other areas in an effort to kick start your own mental processes.  While watching the Bridge to Terabithia with my daughters I was struck by the appropriateness of the song "Keep Your Mind Wide Open".  While it matched the underlying thematic element in the movie it was also very appropriate for this discussion.

By limiting yourself to just IT books and websites and magazines there is a tremendous amount of knowledge that people miss out on.  By opening up your perspective, by keeping your mind wide open, you expose yourself to new possibilities and new ideas that might, just might, change your perspective on a problem and make something easier to solve, easier to build and better for everyone involved.