Andy Leonard : software developers

Third-Grade Math Class

andyleonard — Thu, 13 May 2010 11:00:00 GMT

An Odd Thing Happened... ... when I was in third grade math class: I was handed a sheet of arithmetic problems to solve. There were maybe 20 problems on the page and we were given the remainder of the class to complete them. I don't remember how much...(read more)

Southern Maryland GiveCamp and TBDDEOTP

andyleonard — Thu, 04 Feb 2010 12:00:00 GMT

Introduction I maintain the best way to start a blog post or article is with an image that grabs the reader's attention. So I asked my good friend Frank La Vigne ( Blog - @Tableteer ) to help me out some with his mad Photoshop skillz. TBDDEOTP While describing...(read more)

Software Development Meme

andyleonard — Tue, 01 Jul 2008 02:15:00 GMT

Frank La Vigne called me out on the Software Development Meme, so here goes:

How old were you when you first started programming?

I was 11 - almost 12. It was 1975, about this time of year. Has it been 33 years? Goodness...

How did you get started in programming?

I lived in the sticks (we had to pipe in sunshine but moonshine came in Mason jars...) when our neighbor retired from the Air Force. John was an engineer and built a Southwest Technical Products Motorola 6800-based computer trainer from a kit, followed by a computer.

What was your first language?

I learned M6800 machine language on the trainer. Set the toggle switch up for 1, down for 0, IncAddr, LDAA switches, etc. I learned BASIC later that year - we had no persistent storage so we had to key in hexadecimal from Byte magazine for a while before actually coding BASIC, if we got it right. Usually John would read and I would type. It was cool.

What was the first real program you wrote?

I wrote a program to track weather systems across the US. The grid was initialized with periods and storm system centers were represented with asterisks.

What languages have you used since you started programming?

Goodness...

Many variations of BASIC including GW and Commodore
C
Programmable Logic Controller (PLC) ladder logic (Allen-Bradley, Seimens, GE, Modicon, others...)
Human-Machine Interface (HMI) languages (RSView, Wonderware)
A handful of proprietary classified languages and protocols while in and working for the military
Several proprietary languages used in the banking industry to manage ATMs, teller currency dispensers, and alarm systems
Visual Basic, versions 2.0 - present
VBScript
JavaScript
HTML, ASP
PL/SQL
Transact-SQL
SSIS
SSRS

These days I work with T-SQL, SSIS, SSRS, and VB.Net scripting inside SSIS and SSRS.

What was your first professional programming gig?

Programming was a hobby for a good couple decades (it is still my hobby). I found myself programming at a lot of jobs before it was my "job." I programmed "stuff" while in the military during the 1980's, and banking systems for about five years in the late 80's/ early 90's. I programmed machine controllers (PLCs) and HMIs while an industrial electrician. Once I became an engineer, I programmed even more of these systems. But I suppose my first official programming gig was when I started my first business in the mid-90's. I was regularly able to attract and deliver software projects in between designing and building electrical control systems.

If you knew then what you know now, would you have started programming?

Without reservation! As I stated, programming remains my hobby!

If there is one thing you learned along the way that you would tell new developers, what would it be?

Continue learning and growing. Don't expect things to stay the same. If uncertainty bugs you and/or you need stability for your long-term peace-of-mind, you're in the wrong field. Keep learning. If you enjoy learning, you're in the right field.

What’s the most fun you’ve ever had … programming?

I have a good friend who works for NASA. Bruce showed me this application that allowed him to connect to some big network NASA could access in the early 90's. The application showed him pages with links which was cool in and of itself, but what really got me thinking was that it ran on his Sun workstation and his Mac. What's more, there was a version that would run on my 486. Whoa! Cross-platform, and it looked and acted the same! It was Netscape and I immediately bought a copy (I think I paid $56 USD). I learned HTML. About that time, Rockwell bought Allen-Bradley and produced a suite of drivers that allowed me to communicate between VB (or VBScript) and an industrial RS-485 network of PLCs running at (a screaming) 19.2 kbps. I was inspired. I wrote an app in VB3 that would read registers in the PLC and generate *.htm files every 10 seconds. Folks in the plant - anywhere in the plant, running almost any platform - could see the latest counts and temperatures and process data from these machines - all the time! They just had to hit the refresh key. I realized later I had written the beginnings of one of the first web-based Manufacturing Execution Systems (MES's) - called Decision Support Systems at the time.

Who are you calling out?

Steve Fibich
Kevin Israel
Jessica Moss
Kalen Delaney
Denis Gobo

I would call others if they bothered to blog!

:{> Andy

Speaking In Kansas City

andyleonard — Thu, 15 May 2008 03:01:00 GMT

I'll be in Kansas City next week doing some SSIS training. I don't think I've ever been to KC so I'm looking forward to the trip!

When I found out I would be in town, I dutifully contacted the Kansas City SQL Server Users Group to see if they were having a meeting. When traveling I like to check out Users Groups to see what other folks are doing and also to learn something!

The Kansas City folks decided to hold a meeting since I was available and willing to speak, so I'll be talking about Change Data Capture, Incremental Loads, and SSIS 2008 Tuesday, 20 May 2008. I'm looking forward to meeting as many people from the area as possible!

:{> Andy

Kevin Hazzard on LINQ To SQL

andyleonard — Fri, 09 May 2008 03:54:00 GMT

Kevin Hazzard did an outstanding job presenting to the Richmond SQL Server Users Group this evening on LINQ To SQL!

I really like the ORM / code generation aspects of this new feature of the .Net Framework 3.5. Seeing it in action made me yearn (a little) for my application developer days.

Kevin's VPC crashed a couple hours before his presentation so he recreated the presentation and three demos in 1.5 hours before the meeting - and they were not simple demos, especially the last one.

It's always cool to watch technology in the hands of a master.

:{> Andy

On Technical Leadership: Things Get Easier

andyleonard — Wed, 07 May 2008 18:00:00 GMT

Introduction

A long time ago in a place not so far away from Farmville, I learned Motorola 6800 machine code. It wasn't easy but with patient instruction from my neighbor, I was soon making things happen on the computer screen and in memory. I was hooked!

Fast Forward 3.3 Decades...

I'm still hooked! That thrill was and remains my motivation for doing this work. I've learned it's contagious and I think that's a good thing.

I now use higher-level programming languages to accomplish screen and memory interaction, but it's the same thrill when it fires up and runs. I've noticed a trend over the past three decades or so: interacting with the machine is now easier. It's not just that I can do more in less time - the things I can do are easier to learn (for the most part) while being more complex, flexible, and powerful.

I am reminded of a scene from a Star Trek movie (Star Trek IV - I'm talking old school Star Trek here) where Scotty interacts with a 1984-era desktop. At first he speaks to the computer. When the computer doesn't answer Dr. McCoy hands him the mouse, which Scotty then speaks into as if it's a microphone. It's a funny scene and one that makes sense. The rest of the scene departs from the reality expressed in the first part as Scotty cracks his knuckles and begins frantically typing at the keyboard to ultimately reveal the molecular structure of tranparent aluminum.

The reason I call this a departure? Things get easier. Scotty could no more return to 1984 and interact with a program than you or I could travel back in time to the mid-1940's and program ENIAC.

And We Liked It!

Things were different when I learned M6800 hex. I had to learn about registers and accumulators and bit-shifting - things that still occur inside the CPU but that we rarely have to think about to develop software these days. Why? We use higher order languages.

As mathematics gives way to geometry and algebra, and then to the Calculus, our knowledge of software development has built upon itself as more powerful and more complex generations of programming languages have evolved. Gone (mostly) are the days of punch cards and keying base 16 numbers - which, believe it or not, were a vast improvement over previous methods.

Even though some of us grumpy old men may have liked it that way, things changed.

Things Got Better

Abstraction allowed us to do more. It allows us to manage (or at least mask some of) the complexity of software development. It also allowed us to do it faster. There's a natural progression from simple-and-less-functional to complex-and-more-functional. We're surrounded by it in nature. It's here and it's not going anywhere soon.

Grow with it or be overgrown.

It's the law of nature we inherited, overloaded, and extended to use in software development. It will not change.

That doesn't mean it's perfect - it's not perfect. Joel Spolsky (very effectively) argues abstractions leak and leaky abstractions ultimately slow us down and add work.

In The Box

So how can I say things got better? Allow me to qualify that statement: Generic things got better.

So long as one remains within the confines defined by good people in charge of the abstraction in the first place, things will usually go well. It's when one approaches (or crosses) the edge that stuff gets all whacky (that's the technical term). Stay within the box or prepare to slay the dragons.

Should abstraction work this way? That's open for debate, in my opinion. The fact that it is - and finding some way to effectively deal with it - is a more productive discussion.

How Not To Do It

As a consultant I visited a shop that had experienced a recent turnover in their database department. The new team was in place and they were committed and eager and excited to set things right about the previous crew's work.

Now.

If you walk into a situation like this as a consultant, several red flags should be flapping loudly as they are hastily raised in an increasingly turgid breeze in your consulting brain. If you find yourself sitting in an interview and the interviewer says something along the lines of "Everyone quit," several questions should leap to mind, including:

Why did everyone quit?

But I digress...

I was tasked with converting a process from an older platform to a newer platform. The older platform was poorly documented. Which is to say there was nothing written down, but there did exist a screencast recorded by one of the developers of the application - no doubt after he'd submitted a notice - containing a rambling explanation that most likely made perfect sense to anyone who built the application in the first place, but did very little for someone walking in the door with no experience using the application.

So I asked one of the fresh new team members for help. The response: "Have you seen the video?"

It's difficult to grasp the tone of this response when written as above. So let me add the additional message that was being communicated: "When I started this position n months ago this was all I had and I hated that I did not have more to go on, but I also ignored the large collection of red flags during the interview process and found myself stuck in this job with no net after leaving my last position. And now you walk in with your fancy I'm-here-to-save-the-day attitude and high hourly rate and you expect me to share anything I've learned with you? Ha!"

Did I mention this was a fun gig?

My point is this: You don't do anyone any favors by amplifying the inherent difficulties of abstraction. You don't personally benefit from it, and neither does anyone else.

Footnote: All members of the "new" team at this location have either moved on or are about to.

How To Do It

The way to overcome the inherent difficulties of approaching the boundaries of abstraction is to understand the stuff that's being abstracted.

"But Andy," you ask, "doesn't that undo the benefit of abstraction in the first place?" I'm glad you asked. It certainly can, but this can be mitigated. How? In stark contrast to the exchange above, team communication and collaboration is one way.

Another way is to only hire people who know everything. This second option can be pricey, but can also be worth the price. To quote Andy Warren, "It depends."

Conclusion

Regardless of how we choose to deal with the overhead associated with managing abstraction, manage it we must. Even with its inherent difficulties, it is the way we will progress for the forseeable future.

:{>

Finishing Up Better

andyleonard — Mon, 05 May 2008 03:01:00 GMT

More Better

Last week I read and blogged about Better by Dr. Atul Gawande.

In Part III of the book, Dr. Gawande focuses on Ingenuity with three chapters entitled The Score, The Bell Curve, and For Performance. There are lots of good takeaways for software development in these chapters.

Full Disclosure

One stood out in particular in The Bell Curve. This chapter's use case is Cystic Fibrosis treatment centers. The Cystic Fibrosis Foundation (CFF) has been collecting statistics on centers around the United States for decades. Motivated by a grant from the Institute for Health Care Improvement, the centers began "opening up" about their performance compared to other centers.

Everyone wants to feel like they're doing a good job - in medicine, software, and every other field on the planet. Almost everyone has good and noble intentions. But some folks just do things better than everyone else. Why not identify those folks - those Positive Deviants - learn what they're doing that's so different, and try to reproduce those results everywhere?

Excellent question.

The answers are difficult because they cover the range of excuses for every bad idea ever conceived in human history. In the best case and strictest sense of the word, it's due to ignorance: People simply do not know any better - they're doing the best they can. The worst case is probably incompetence with a dash of malice to hide the fact.

Opening up changes things. It opens the door for the sharing of best practices by those who have developed and are practicing them. How cool.

Pulling Away

Perhaps the most potent example of best practices is found in a statement about the leading CF centers:

"You look at the rates of improvement in different quartiles, and it's the centers in the top quartile that are improving fastest," [Bruce] Marshall [the head of quality improvement for the foundation] says. "They are at risk of breaking away." What the best may have, above all, is a capacity to learn and change - and to do so faster than everyone else.¹

This theme, while emphatically true and accurate, is abused by Performance-Based Management. Beware too much of a good thing, regardless of the thing.

Conclusion

There are ways for us to do our jobs better. We can make software with higher quality and lower maintenance costs. We need to embrace the principles outlined in Better, identify and mimic those people who are Positive Deviants, and overcome all obstacles between the current state of affairs and our goal.

I not only know we can, I believe we're well on our way.

:{> Andy

¹Better, Dr. Atul Gawande, p. 227.

Better

andyleonard — Wed, 30 Apr 2008 03:01:00 GMT

It's The Little Things...

In Better, Dr. Atul Gawande mentions several basic things medical professionals can do to drastically impact the rate of hospital-passed infection. His first point is: Wash your hands.

This seems simple on the surface, but the time requirements for properly washing one's hands using traditional soaps is noteworthy: Once specified and quantified, this becomes a time-consuming exercise.

The procedure:
- Remove watches and jewelry
- Wet your hands with warm water
- Dispense soap and lather everything from 1/3 of the forearm down for 15 - 30 seconds
- Rinse for 30 seconds
- Dry completely, then use the towel to turn off water.
- Repeat after any new contact with a patient.

   Let's try to be realistic and say we can remove our watch and jewelry in 6 - 10 seconds. We can turn on the water and wet our hands in 5 seconds. We have 45 - 60 seconds lathering and rinsing. Then 15 seconds drying and finishing up. That's 1:11 - 1:30 each time a medical professional touches a patient.
   Add to the mix: some medical professionals are expected to interact with 20 patients per hour. That's 3 minutes per patient - and nearly half of that time is to be taken doing "unproductive" work - washing one's hands.
   Why do they do it? People die if they don't. The statistics are sobering: 2 million people annually catch a bug in the hospital in the US alone. 90,000 of them die.

Of Hand-Washing And Software...

Andy, what does any of this have to do with software?

I'm glad you asked. Like Dr. Gawande and lots of you, I believe we can also do Better. What's the equivalent of "washing our hands" in software development? My friend Harper Trow says "if you mean the most basic practice - the most common sense, I would say use source control". Harper also points out source control is Item #1 on Joel Spolky's Joel Test post.

Now you don't need to use source control. And you don't need health insurance. These are equivalent statements, unless you are (and will remain) in perfect health or are (and will remain) a flawless coder. Source control is not suspenders-and-a-belt - it's a belt and you have no suspenders. You need it or you're in danger of showing something you (or we) may not wish to see. It's as optional to the software development process as security to the information technology enterprise.

Source control can be setup and configured in a day, learned on Day 2, and mastered in a week. You don't have to start with a full-blown Application Lifecycle Management (ALM) Suite, you can grab an open-source project or trial edition and install it on your Dev server. Most products integrate into Visual Studio and many into SSMS. It's not hard, it just requires a bit of discipline and the desire to do better.

Changing

Dr. Gawande cites several attempts, some successful and some not, to implement change in the personal habits of people - change which is literally a matter of life and death.

The failures of these attempts are staggering.

The implication for us is this: If humans are incapable of change when life itself is on the line, how much less capable are we when it's "just software?" This is my theme and central question.

What makes developers change habits? What causes DBAs to do things differently? What drives us? motivates us? changes us? makes us better? Is it even possible?

What Worked?

At the veterans hospital in Pittsburgh, Jon Lloyd attempted a strategy based on Positive Deviance. (Positive Deviance is exemplified in Good To Great - an awesome book on patterns of business success.) It worked like this: They held short meetings with everyone in the hospitals. Everyone. Doctors, nurses, janitors, food service workers, even patients. They made one statement: We're here because of the hospital infection problem and want to know what you know about how to solve it.

Holy smokes. Asking the people that do the work - that's crazy talk!

It worked, but not for the reasons you may think. It worked because it engaged the population. When anyone actually acted on the ideas presented - which by and large were repeated in every 30-minute meeting - the people in attendance felt someone was listening to them and responded by helping implement their own ideas.

Someone break out the bold red font. This is important. Engaging people works. Someone should tell user groups! Oh wait, someone did! ;)

Listening, then acting upon what's said, prompts participation like nothing else. There is no substitute. How's a leader to get started?

Here's How To Start

Invite the team to lunch and pop the question. No, not that question. This one: "What do you know about doing our job better?" Let the ideas flow - don't respond and for goodness' sake do not defend anything. Listen. Then listen some more. And then - you got it - listen yet more. Make notes. Nod. Engage.

And then implement some of the suggestions.

How hard is this? Everyone likes to be appreciated and almost everyone wants to do a good job. Lead them. By example. You want them to do a good job? You do a good job leading first. You be Better first. Unless, of course, you want them leading. ;)

:{> Andy

Dreaming In Code

andyleonard — Sun, 20 Apr 2008 03:50:00 GMT

A month or so back I was perusing MSDN Blogs and followed a link to the Dreaming In Code website.

I bought it and finished reading the book on my way home from the MVP Summit last week. I recommend it to anyone who wishes to learn more about large software projects.

The book offers a look behind the scenes at the design and development of an open-source Personal Information Manager project named Chandler. Chandler was initially touted as "The Outlook Killer" and the book describes Mitch Kapor's frustration with Exchange as one motivation for starting the project.

I found the book a fascinating look into

the work that goes into large projects;
the team dynamic as applied to software design and development;
open source development.

The book is slightly biased towards open source development and the open source community, but it's subject is an open source development project so the bias is expected. That shouldn't prevent anyone from reading the book. The challenges and pitfalls of producing great software bear no respect for platform or language.

One of the points the author drives home is how little we as developers and IT professionals study our own field. If you read my ramblings, you are probably not in that crowd.

The book's conclusion (and several reviews) led me to believe the project is a failure. I disagree - I don't think it's finished yet. Some things take time. Good software sometimes - often, in fact - takes more time than anyone can foresee at the start.

:{> Andy

Microsoft Announces SQL Server Data Services (SSDS)!

andyleonard — Wed, 05 Mar 2008 19:08:00 GMT

Cool things are coming out of Mix08!

There's even something there for we database people: SQL Server Data Services.

From Neil Hutson's blog:

SSDS you can think of as a structured data store in the cloud(building block service), which is accessed using Internet protocols using a basic data manipulation language. SSDS is for developers and businesses that need scalable, easily programmable, and cost-effective data storage with robust database query capabilities. Pretty cool.

:{> Andy

SSIS and Visual Studio 2008

andyleonard — Wed, 28 Nov 2007 14:17:00 GMT

Harper Trow of GenYSystems tells me he cannot open SSIS 2005 packages in Visual Studio 2008. I have not yet confirmed this personally but I trust Harper implicitly - he's one of the smartest developers I know. More later...

In a related story: there's a download that allows you to interact with SQL Server 2008 CTP 5 from within Visual Studio 2005. Check out Visual Studio 2005 Support for SQL Server 2008, Community Technology Preview.

:{> Andy

Context and Grain

andyleonard — Sun, 04 Nov 2007 00:41:00 GMT

Introduction: The World Series (1979) and Photography

Willie "Pops" Stargell started my interest in photography (...a funny way to start a post on a SQL Server blog site, but bear with me). Pops Stargell led the 1979 Pittsburgh Pirates to win the World Series. He was the MVP that year as well.

My Mom, in the only time I ever remember her gambling when I was a kid, bought a $10 spot in a World Series baseball pool that year. The pool was based on the 1's digit of the total runs scored by the Pirates and Orioles in the entire series with the person who had the 1's digits in the correct order winning $600, the person getting them in reverse order winning $300, and the organizer kept $100. The series lasted seven games that year. Mom was set to win the $600 if the final score of Game 7 was 4-1 in the Pirate's favor. Willie Stargell hit a home run that helped achieve that score, along with some good fielding (especially for a 39-year old player).

I had a budding interest in photography because some friends at high school were photographers. There was just no way we could swing $200 for a mid-range 35mm SLR back them. But Mom promised me if she won the big money she'd buy me the camera. She won and she bought me the camera.

I got to attend an interesting Yearbook Seminar the next summer held at Longwood University in Farmville, VA - located about 7 miles from where I currently live. I learned some fascinating things about photography and did a decent job getting shots for my senior year yearbook.

Photography Context and Grain

One of the things I learned was this: If you take an out-of-focus shot, there's nothing you can do in chemical and light processing to bring that shot into focus. There may be (and probably are) digital things we can do nowadays, but this was the 70's. The very best you could do with an out-of-focus was produce a print no less in focus.

In the context of the photograph, the focus attribute was set when the picture was taken. The focus could not be improved after the picture was taken. It was the best it was ever going to be from that moment until forever.

Database Design Context and Grain

Now here's a lesson we can take into database development.

Several for-instances leap to mind: granular resolution in a business intelligence data acquisition system, for one.

Imagine you are tasked with reporting real-time data for a business intelligence scorecard application. The client expects up-to-the-second updates from the data acquisition systems on the manufacturing floor and this is a project requirement.

Sure, you can do that.

Unless data is collected every five seconds on the floor. Then you have an issue. There's nothing you can do from your side of the project - since you merely read, store, transform, and display the acquired data - to "fix" this. You can give updates every second, but these counters (and metrics derived from them) will change only every five seconds.

In this imaginary scenario you cannot "re-focus" the picture. The best you can do is present the information at it's current grain - and no finer.

Software Development Context and Grain

The same can be said for software development. I will state it in another way: Every decision to develop Feature A in a certain way is also a decision to not develop Feature A in any number of other ways.

There are consequences to choosing an approach, methodology, or context. These consequences are usually discovered well down the path towards a deliverable or release. Occassionally, talented developers can find a "silver bullet" - a fix that solves the current consequence to a past decision without breaking anything else. But this is unfortunately rare. Usually there are consequences to the consequence-initiated fix, and so on, ad infinitum.

There is a point early on in a development project where such consequences, if detected, can be addressed with relatively little effort. I use the analogy of deflecting an approaching asteroid: If you detect it early enough you can deflect it with a BB. Wait, and all the nukes on the planet won't stop it.

One rule of processes - I first saw this in The Goal - is "Losses accumulate, gains do not" (just call me Mr. Encouraging). Most good process measurement methodologies account for this. One way to think about it is to consider the example of a three-stage linear process where each stage is running at 90% efficiency.

<TrickQuestion> What is the overall efficiency of the system?
<TrickAnswer> 90%</TrickAnswer>
</TrickQuestion>

90% is incorrect. It's a linear process. The output of stage 1 is 90%. The output of stage 2 is 90% of 90%, or 81%. The output of stage 3 is 90% of 81%, or 73%.

Consider a process-improvement initiative that results in 100% efficiency at stage 1. The output improves, but only to 81%. Consider the alternative - a reduction at stage 1 to 80%. Stage 2's output becomes 72%; stage 3's: 65%. The losses accumulate, the gains don't. To quote Foghorn Leghorn, "Figures don't lie."

Why Are You Sharing This, Mr. Encouraging?

There are a few reasons: First, this is a trap into which many a young developer falls. It looks simple but it is not. Life is filled with things that appear deceptively simple. Software development is but one of them.

Second, underestimating the effort required to accomplish any software related task is a trait shared by every good developer I know, plus me. We all think things will take less time than they do. I don't know why, but that doesn't make the fact any less true. Joel Spolsky has an excellent article on Evidence Based Scheduling that presents an interesting solution to this.

Third, it doesn't matter how good you are, this can happen to you. The odds of getting caught in a process-resolution trap increase exponentially with complexity.

Conclusion

Be aware during design / architecture phases, the decisions made today will limit future options. There's a side order of art included with the science here. Balance is the key.

:{> Andy

Bad IT Project Management

andyleonard — Thu, 09 Aug 2007 10:52:00 GMT

My sister-in-law recently passed the PMP certification (congratulations Heather!). I'm waiting for a call from her asking if we need to add resources.

The resources comment above is a joke, but it isn't really that funny. It's indicative of my decades of experience with bad IT project managers.

I believe and hope I have worked with some of the worst project managers on the planet. Why do I hope? I'd hate to think anyone has had to deal with folks worse than the poor project managers I've dealt with.

As I type, we're experiencing a heat wave in Farmville, Virginia. It was 107 degrees Fahrenheit here yesterday. It's the "dog days of summer", as my Granny used to call them.

Somehwere, you will find 30 or more push mowers lined up wheel-to-wheel along one axis of a lawn. On command, the 30+ operators will start their mowers. On cue, they will push them across the lawn, maintaining the wheel-to-wheel alignment, cutting the entire area in one pass.

This, my friend, is the home of an IT project manager.

My experiences have led me to a couple thoughts:

Frederick Brook's The Mythical Man-Month should be required reading for all project managers.
Proof of callouses should be required for the application process.

(The same can be said for MBAs, but that's for another post...)

Inspired by the book, Brook's Law states "Adding manpower to a late software project makes it later." It is perhaps best summed up by the following statement by Brooks himself: "The bearing of a child takes nine months, no matter how many women are assigned."

As an IT professional, you can learn to detect when you're about to be "managed". I share the following indicators and advice from my years of experience:

"Do we need to add more resources?" This question in and of itself is harmless. It's actually the way project managers greet each other and has no more meaning to ordinary folk than "How are you doing today?" or "How about this weather?"

The best answer to this question is a non-answer. After years of trying to correctly answer this (as though it were a meaningful question), I stumbled across an answer that works for me: "I don't know." Why does this work so well? The last thing a bad IT project manager wants to do is make a decision - at least one traceable to them.

"I am (or used-to-be) a software developer." If you hear this, you're in trouble. Big, big trouble. My advice to you is to vacate the project - and the premises - as quickly as possible. This isn't a fire evacuation, it's a bomb evacuation. You may wish to consider jumping out a window if you're on or below the third floor.

Why? You are dealing with a person who believes they were promoted because they were such a good developer. Mind you, this is true in less than 25% of my experience. And even then, odds are their resume includes COBOL or they aren't nearly the project manager they believe themselves to be. At best you have 1/3rd of a 25% chance that you're working for someone who knows a definition for delegate - a definition that isn't "someone who attends a convention."

The truth of the matter is this person was likely promoted before they could delay or otherwise further damage the software project to which they were assigned.

"What do I tell my boss (or the stakeholders)?" This question is the prelude to a demand. Your answer isn't important, the demand in the mind of the IT project manager is important. And that demand is for you to do something no sane developer would ever do.

There are a couple options. If you're feeling froggy, you can document the fact you were asked to take this ridiculous course of action by your IT project manager, and then do it. Be sure to address the issue in writing and as soon as possible. CC someone else - anyone else. If you can CC the project managers' boss without looking like you're trying to make them look stupid, that's best. If not, CC someone else at your level on the development team (and allow the bad IT project manager to continue their work of making themselves look stupid unassisted).

Note: Never BCC. BCC'ing the boss is the equivalent of placing a bold, red, flashing banner across the top of your message which states "I'M INSECURE". The boss will get this message, loud and clear. Go ahead and CC them if you believe it's warranted - those dogs need to wake up eventually.

Make sure it's in writing and someone else sees it - that's the point.

The other option is to simply ignore it and do what you know to be right and good. There's risk here too. Some bad IT project managers will call in bigger dogs to shout you down. It's good to have your mugshot and name on a book somewhere if you're going to exercise this option.

"Umm yeah. I'm going to need you to come in Saturday. Sunday's not looking good either..." People are people. Bad IT project managers don't get that. They call people "resources". People aren't resources, we use resources, but we're separate and distinct from resources. People are people.

Bad IT project managers are the reason we have IT Project Leads. After all, someone who knows what they're talking about needs to have some authority if any software project is to stand a chance of succeeding.

:{> Andy

PS - This post inspired a new category at Applied Team System: Expensive Management Practices - gotta love the acronym. :{>

A Follow-up to Database Professionals: An Enterprise Requirement

andyleonard — Sat, 14 Jul 2007 01:07:00 GMT

Eric Wise drew some heat from the developer community at CodeBetter.com with this post about the need for a DBA during development (see my post on the subject here).

I think Eric makes a couple good points, one explicit, one implied:

1. (Explicit) A DBA - or Database Developer, more accurately (and there is a difference) - adds value to development.

2. (Implicit) There are Software Developers out there who can step into the Database Developer role long enough to solve most database tuning issues. Eric demonstrates this with himself in profiling and addressing a missing or ill-defined index.

I find most of the comments - presumably by software developers - typical. One developer stated:

My current project didn't have a DBA for 2 years, until recently since we're now at the stage of optimizing for performance. It seems to me that as long as the database is intelligently structured in the first place, a DBA's role would be rather small in most cases.

I agree with the sentiment expressed here - as much as I agree that code-generation tools can replace application developers. It's true that you can utilize SQL Server or any database engine as a dumb file store. And it's equally true that you can build an enterprise application in C# that consists of thousands upon thousands of lines of nested If... Then... Else statements.

</sarcasm>

The question is: Why would you?

This goes beyond arguments over syntax, coding standards, methodology, and design philosophy. This is about putting competent professionals - at the height of their game - into the mix on a project.

You don't have to take my word for it - ask software developers who have worked (or are working) with competent database developers.

:{> Andy