Sunday, November 19, 2006

Size Matters

Okay, I couldn’t help myself and I promise you’ll find the title is relevant if you read on.

Working with new programmers has challenges beyond those normally associated with a project. When I was a line programmer, just one member in a bigger team, I did not have to worry about these challenges so I did not fully appreciate this fact.

Sure, I knew that new programmers had a lot to learn before they would be useful. Until then, the boss kept them busy working the repetitive patches we need to apply to hundreds of individual programs that made up our applications. Along the way, the new guy usually figured out how we did things and could start doing some real development work.

When the company promoted me to team chief things changed. It turned out; having a new programmer apply patches to hundreds of old programs gives them little else than a basic familiarity with the poor programming habits of those who came before them after which, if they were a novice hack worth their salt, they could write a script that would apply the required changes. Unfortunately, when they jumped into new application development things quickly went south.

Before I go any further, let me step back and set some of the scenery for you. The year was 1990. We were maintaining COBOL programs that accessed data stored on an ISAM database. Both the database and the application were running on a Data General MV/8000 running AOS/VS. Our 200+ end users accessed the applications on dumb terminals. Finally, yes we used two digits to store the year.

Okay, I have to admit, when I look at it, the first thing that comes to my mind is Mr Spock making a statement about a zinc-plated, vacuum tube society with technology scarcely ahead of stone knives and bearskins. However, from a learning perspective, this environment had many benefits. The most important being the great clarity with which you could see the cause and effect of programming decisions in a multi-user environment; which brings me to my real point.

The problem we encountered was the habits new programmers developed in training before they joined our team.

The training environment was a single user environment. For instance, the typical assignment had one program, run by one user access an isolated set of data to produce a report. To enable each student to have their own applications, each student kept their code in their own working directory. To prevent data corruption, students had their own test dataset. To enable students to debug their work, applications ran without interacting with external processes.

Writing code in this limited environment is the definition of programming in the small. The real-world environment where end users ran our applications consisted of hundreds of end users running multiple instances of the same application accessing and updating data stored in a single dataset. Writing code in this interactive, non-linear environment is the definition of programming in the large.

Simply put, the new programmers thought that working in a multi-user environment was the same as working in a single-user environment. Until they accepted that programming in the large was much more complicated and required a different mindset than programming in the small, writ large, they offered limited value to the team.

Fortunately, the stone-knife environment we were working in enabled us to see the challenges of programming in the large and provided an opportunity for each of us to learn how to devise solutions to overcome them.

Additionally, my transition from team member to team manager forced me to take a similar look at the challenges of management and leadership. As with programming, I discovered that “In the Large” activities are much more complicated than “In the Small” activates writ large. In fact, while intimate knowledge of In the Small activities can provide great insight to In the Large issues, more often than not, In the Large activities are a different skill all together.

This is the fundamental problem of the E-Myth where well-versed technicians discover that running a business is much more than providing their value adding skills directly to paying customers rather than an intermediary employer.

If you’re encountering more difficulty achieving success as you transition from being a practitioner of the value-adding technical skills your organization offers to clients to the management and leadership of others who provide that skill, I’ll bet you a dollar that you are working in the small, writ large and it’s time you reevaluated your value proposition.

Subscribe Today; Digg This Article

Take care...

John

No comments: