Monday, Monday

It almost felt good to be at work today. Almost.

Part of it was a feeling of recklessness. I was ready to make some decisions, and make the right decisions, and make them for the right reasons, and ignore the flack that was guaranteed to explode in my face. It didn't matter. The decision had to be made. The course had to be set. The right course.

It seems there's a constant struggle between doing what is right for the product and doing what is best for the Company's bottom line. As an engineer, I lean towards doing what is right for the product, no matter the cost to budget or schedule -- within reason. Obviously, I don't want to put the Company into a bad situation, financially speaking. But I cannot condone abandonment of engineering principle in order to maintain a fantasy that the software is "good enough". There are simply too many unknowns, untested areas, undocumented behaviors.

There's a quote that Management bandies about: "The perfect is the enemy of the good enough". That quote drives me absolutely nuts. What they're trying to push is the idea that engineers are too idealistic, and will pursue a bug into the ground until it consumes all the schedule and budget for the project.

Engineers are not stupid. We realize that the product has to ship before it makes any money for the Company, and it is that money that allows us to go back and create more wonderful projects.

But when there are obvious problems, or areas of the product (especially software) that are not well documented or understood, there is a fear that drives the engineer to dig deep into that problem in order to bring it to close. This is the fear that somewhere, somehow, an oversight on his/her part will bring about a calamity, and that calamity will be traced ultimately to a failure on the part of the engineer with regard to his knowledge, skill, or ability.

Engineers pride themselves in their work. It is where the majority of their self-esteem comes from. Engineers, especially software engineers, have been known to work on software for free in order to impress other engineers with their prowess. Indeed, if this Project were made Open Source, most of the problems would be resolved relatively quickly as a horde of self-righteous, convinced-of-their-own-superiority programmers would descend on the code like Texans to a barbecue and beat it to death until they had resolved every single one of the issues which plague us now.

(Naturally, they'd also introduce a horde of new problems, but that would just give them more impetus to keep going...)

Managers care about the quality of the work, but not so much as they care about meeting the budgets and schedules laid down in the agreements between the Company and the Customer. Why? Because managers pride themselves on their ability to predict an outcome, and then guide the team towards that outcome. In effect, they are proving their prowess in herding a team of cats down a narrow path within a specific time constraint, knowing that success will bring a big reward -- but more importantly, it will prove that they are powerful, capable and respected leaders.

This is why one often hears managers speak about upgrades and updates and patches and nice little buzzwords like that which allow them to get the current job "done" and leave the fine-tuning for later. Even if they don't accomplish all the goals, they will have proven that they can get the product to market in a timely fashion, and that is what business in our capitalistic society is all about, especially in the embedded systems niche. Time-to-Market is what guarantees success, because typically the first one out the door gets the brand recognition, and people will generally stick with the brand they know in the hope that the quality will improve over time.

This is why I will probably never make a good manager, unless my sole focus is to manage people, not products. I care about the people more than the products, actually. I want the people to have fun, to take pride in their work, to be able to look back on a project and declare that they did their best and the product is good. (Not perfect, but good.)

I want to be a part of a great team that has a great time making great products.