Paid Apprenticeships?

A minor rant. I hear now and again someone talking about the old craftsman ways and how an apprentice used to pay his master for services. Now, we expect our first job to pay us well and it is a terrible injustice. To that I can only say that we do pay for our apprenticeships, but it is now called college. Whether you agree or disagree that it is a valuable apprenticeship, it is one just the same and probably had the same value now as it did back in the olden days. So, the next time you think you ought to get paid for taking on an apprentice, go teach school.

More on Company Death

I happen to like the beekeeper story, but I think it is incomplete. The author blames a company's demise on the leader leaving or changing, but I don't necessarily believe that is it. I think projects get larger and mature and they change in nature. Take Office. It doesn't have to get a ton of new whiz bang features out immediately. It has market share and it needs to maintain its dominance while not hurting quality. To do that, you add processes in place to control the change in the product and to ensure integration with other products. I'm curious if this is just natural product evolution. It doesn't have to be company wide. For instance, at MS the XBox, MSN Search, and V. Studio teams are still quite agile and seem to enjoy their jobs, where the larger, integrated systems people are miserable. Is it the leader? Is it integration? Is it complacency (wanting to maintain your product instead of revolutionize it)? Is it all 3? Why do some companies impose process in some areas and not in others whereas other companies impose process over the entire company at one time? What is the survival rate of each?

On complacency, I think that is a valid reason for a while. Office, in the past 5 years, has not had to revolutionize. I think that the open source movement and OpenOffice in particular has forced its hand and required Office 12 to be produced. However, therein lies the problem. When a new challenge faces a process laden product, it can't adapt. The top programmers have left to find projects with less process and processes have been inserted to maintain the quality in their absense. Now, the mediocre programmers are faced with a challenge that is too great for them, create a revolutionary project in Internet time. The processes don't allow it, the programmer's don't have the skills, and the result is a buggy product that is late and not close to what users expect or need.

Do I think MS is on its death throws? Most certainly not. It is too big to go down the tubes over night. However, many people thought the same thing about IBM and it lost huge amounts of market share and almost was divided into many separate, smaller companies. It took Lou Gerstner to turn the company around, eliminate the beurocracy, and get the company agile again. Coincidentally, Lou named his book, Who Says Elephants Can't Dance. It is a must read if you are in the technology sector as it directly addresses a company's shift from beurocracy to agility. Making a large company dance is an amazing feat. In Lou's opinion, it took a leadership change to make it happen. In fact, had he not come in time, they would have spun off many IBM divisions and it would have continued to decline. According to my interpretation of Lou, agility is not something that can come bottom up, it must be a leadership decision.

What about Oracle? How does it handle process? What are the other older and bigger tech companies: SAS, Apple, Sun - what do they do? What about larger tech companies that have failed: DEC, Compaq - what did they do wrong. I've studied Apple's problems and they seemed to stem from arrogance and a fundamental lack of marketplace economics, not process. It was more an unwillingness to change rather than an inability to change. Looks like it is time to hit the books...

The Other Side

I really don't want to promote this guy's blog, but in the interest of fairness, I'll show the other side of the coin. This post describes why a business man believes Microsoft needs more process and more beurocracy, not less.

They just don't get it. There is a known connection between process and productivity, one that until recently I forgot. When labor unions want to strike, but cannot for whatever reason, they often strike "by the book." What this means is that they follow the process manual to the letter. Basically, no work gets done because all of the process gets in the way. It is a very effective tactic. The same holds true for companies, as process is added, productivity drops. The blog talks about the problems with bugs in the old MS software and how process should fix that. WRONG. You can't "process" the bugs out of the system. The delayed release of Vista, Monad, and Office 12 because of bugs shows that process doesn't help that. Instead, it drives away your best developers, causing MORE bugs, not fewer. It just goes to show that business people don't understand the relationship between quality craftsman and quality craftsmanship. They like to think in assembly lines and mass production. I hate to tell them, but the software industry isn't there yet, and may never be.

Of course, many companies don't need the best. They can settle for a prefabricated home instead of a custom built mansion. However, if you're life's work is hosting parties, then you better opt for the mansion and you better make sure it is built well. The same goes with software companies. If you're life's work is making great software, then you better hire and retain the best in the business.

The Perils of Integration

Thinking more about mini-microsoft and what has been posted by him and his readers, I wonder how much a company's downfall has to do with integration. When a company decides to integrate its systems into one mammoth system, it seems to spell doom. I think the process goes like this:

First, some senior executive decides that everything needs to be "integrated." This could mean that everything needs to work together, run on the same box, or in the same environment, who knows the exact definition?

This decision spawns a massive project and a few reorgs. The massive project introduces hundreds, if not thousands, of dependencies between teams. Managing these dependencies becomes too much for the teams and therefore process has to take over. The system is fragile and buggy, but any change to the system has to be approved by everyone else, and may cause everyone else to recompile or recode their part. Therefore, changes are to be avoided at all cost. It begins to take longer and longer to put out a release.

At this point, the individual teams have lost all power. The power is centralized into a few leadership individuals who make decisions, but don't know the technical details of those decisions and therefore can't understand the ramifications. It's not their fault, there are too many dependencies for ANYONE to understand all the ramifications. The teams can no longer respond to customer needs; they'd like to, but their hands are tied because if they change the Foo widget then it will cause a recompile of 5 other libraries and 2 months of testing - and the testers are already running on empty.

The best programmer's get frustrated. They can see the problem, but they can't put their finger on what exactly is wrong, plus they spend more time filling out forms and "communicating" then they do programming. They get disgruntled and leave for greener pastures. Those who remain are left maintaining systems that they didn't build and changes to the system are slower and more painful than before.

Finally, one of two things can happen, either the company can fold, or some spark occurs and the old, integrated system is left for dead and a project is started to build a new system that relies on customer teams and independence. The best programmers are hired to create the system and it becomes a success. Then the cycle repeats itself again.

Integrated systems are the hardest things to do correctly. As I've mentioned before it is our job to manage dependencies. The best way to manage a dependency is to eliminate it. With an integrated system, you have the potential to create an exponential number of dependencies, thus ensuring the demise of your company. Now, the question remains: how do you create an integrated system correctly? I'm not sure, but I'm going to think on it, so keep checking back here for the/an answer.

Mini-Microsoft and the Death of a Corporation

Mini-Microsoft is an anonymous Microsoft employee that is trying to change his company by airing its dirty laundry, publicly. I don't know that I agree with his approach, but I certainly feel sorry for him. It is sad to see a corporation leave the expansion phase and go into the recession phase, but all the signs are there. They have reduced or stopped raises, their earnings are slumping, they are using reorgs as a way to increase productivity, they are using process over people, and their best people are abandoning ship while those that stay have low productivity due to low morale. Microsoft had one of the longest expansion periods I've seen. Now, the giant has peaked and it must move into a recession phase. This is not to say that sometime, in the future, it can't expand again, but it must fall hard before that is to occur. Some of its products will decline as well, some have already been in decline. Some of its products may even excel: I'm a huge fan of C# and I think it will do well, though lack of true multi-platform support may hinder it (sorry Mono, you're not there yet). The warning signs are clear and its sad for the 50,000 people that work there. So long and thanks for all the phish.

C++ Tip: lower_bound and functors

Here's an interesting thing I learned recently via necessity. Let's assume you have a vector of string/int combinations.

vector<pair<string, int> > myvec;

Now, lets assume we add data to the vector, in sorted order (based on the string).

myvec.push_back( make_pair( string("A"), 0 ) );
myvec.push_back( make_pair( string("B"), 1 ) );
myvec.push_back( make_pair( string("C"), 2 ) );
myvec.push_back( make_pair( string("D"), 3 ) );

Finally, we want to search for a string key in the sorted vector using lower_bound.
We can't do the following:

lower_bound( myvec.begin(), myvec.end(), 
             string( "C" ) );

It will complain that there is not an operator<(std::pair<std::string,int>, std::string). Well, that is annoying, but we can write one. However, it is usually better to not clutter the global namespace with such functions and instead we choose to create a comparator function.

bool pair_str_less(const pair<
                     string,int>& lhs, 
                   const string& rhs)
{
   return lhs.first < rhs;
}

Now we pass in the comparator function

lower_bound( myvec.begin(), myvec.end(), 
             string("C"), pair_str_less );

Ouch! Now it complains that there is no pair_str_less( std::string, std::pair<std::string, int> ). It needs both permutations of function arguments! Unfortunately, we can only pass in one comparator! Perhaps it is not meant to be? Maybe we should just write our own version of lower bound? Or perhaps we should create a dummy std::pair from the string? Or, perhaps we can use functors!

struct pair_str_less
{
   bool operator()( const pair< 
                      string, int>& lhs, 
                    const string& rhs ) const 
   { /*...*/ }
   bool operator()( const string& rhs, 
                    const pair< 
                      string, int >& rhs ) const 
   { /*...*/ }
};

Now, we can use the pair_str_less function like

lower_bound( myvec.begin(), myvec.end(), 
             string("C"), pair_str_less() );

and the right version of operator() is chosen each way. Yeah!

Process vs Best Practice

I'm tired of process. Yes, I know it is supposed to help. Yes, I know it encourages responsibility and increases quality and decreases entropy and blah blah blah, but it is WRONG.

If you hire the smartest people, give them the best tools, and let them work, they will do the right thing, intrinsically. You only need process when your people have let you down. In fact, when you institute a mandated process, you are slapping your employees in the face. You are saying, "I don't trust you to get this right, so I, your leader, have mandated that you must follow these steps." The best people will follow the best practices. They will use version control, bug tracking, and change management because it is the right thing to do, not because someone forced them to do it. Moreover, they will also be able to choose when not to use it. The problem with process is that it must be blindly followed. It will bog your people and your company down in its forced standards. It will lower morale due to trust issues. It will lower morale due to developers being forced into the "one right way" (developers naturally resist standards and blind obedience).

Get the right people on the bus and get the process off the bus. Let the people find the best practices and let them have a great time producing great code.

C# 3.0

There was a recent post on slashdot sending people to view a video of Anders talking about C# 3.0. For those who don't know, Anders Hejlsberg was the creator of Delphi and the Object Pascal language. Microsoft hired him away from Borland to oversee their .NET languages. While I think C++.NET is an abomination, C# is an amazing staticly typed language. It has stayed away from all of Java's problems and has adopted a much more agile flavor: very ruby-ish in nature. I've been reading the O'Reilly book on C# 2.0 and I've been impressed, but 3.0 looks like it will blow all other static typed languages out of the water. Kudos to Anders for giving us a language worth using. Now, I wonder about performance...

Another thing I found interesting about this video was Anders continual discussion of the "shape" of data. I've heard this term before (I think it was in Code Complete), but it had been a while. Acutally using C# to show the difference between rectangular data and heirarchical data was very interesting to me. It is something I'll have to start thinking about on a regular basis.

Dependencies

One of the most important jobs a programmer has is to manage dependencies. In fact, many of the Code Smells that we learn to avoid have their roots in the removal of unnecessary dependencies.

Especially evil are implicit dependencies (i.e., dependencies that are not easily noticed/not explicitly written). For example, once and only once is about the removal of implicit dependencies. Why? Because all instances of duplicated code depend on each other. If you have the following lines

int i = 0;
for( ; i < 10; ++i )
{
  ...
}
i--;

and you decide that the last i-- is a bug, then you have to remove the last i-- in every instance of the duplicated code - they are all dependent on one another. What's worse is that there is no semantic information associated with this code. It could be that one instance of the duplicated code actually precedes something slightly different so that the i-- is actually needed. Because there is no semantic information tieing all the pieces together, there is no way to know which i-- should stay and which should go.

Magic numbers, being another form of code duplication, have exactly the same problems; however, the problems with lack of semantic information is exacerbated with magic numbers. In the code above, there is no knowledge of what the number 10 represents. When you realize that it should be 15 do you change all the instances of 10 to 15? If not, how do you know which ones to change and which ones not to?

Dave Chelimsky discusses how to Manage Dependencies Not Aesthetics in his blog. He uses the following example:

display.print( person.getAddress().getZipCode() );

and then compares it with

display.print( person.getZipCode() );

and

person.printZipCode(display);

Which one has its dependencies managed correctly? Let's examine where the dependencies are. In example 1, there is a dependency from the main code to display, person, address, and zip code. There is also a dependency between display and zip code. Even though zip code is just a string, there is a logical dependency between the concept of a zip code and display.
In example 2, there is a dependency from the main code to display, person, and zip code. The dependency on address has been eliminated. There is still a logical dependency from display to zip code. In example 3, there is a dependency from the main code to both person and display, the dependency to zip code has been removed (even though the function still says zip code, the zip code is not seen or used in the main code, so there is no dependency). There is an additional dependency between a person and a display object.

Now, elimination of dependencies is not the goal, only the effective management of dependencies; however, it is much easier to manage a dependency that doesn't exist, just like it is much easier to maintain code that doesn't exist. I think we can quickly eliminate example 1 as being the best because it has no advantages over example 2 and an additional dependency. Example 2 does have an additional dependency over Example 3, but there are some trade-offs involved. With example 2, if the zip code changes, then the display class must also change. With example 3, if you want to write to something other than a display, then the person class must change. So, the question becomes which is more likely to change. Obviously this will change on a design by design basis.

Interestingly enough, the comments section of David's blog dives off into a discussion of formatters and visitors and how to isolate the change, but each introduces more dependencies in an effort to find the best dependency combination that is least likely to change. In this case, I might stick to the TDD principle of doing the simplest thing possible and then refactoring when we actually see the change, at that time you can make a more informed decision about what needs to be changed and how the change needs to occur.

J - A - C - K - E - TS

My daughter just cheered at her first game. Kindergartners through fifth graders had the chance to be "mini-cheerleaders" at tonight's football game. My daughter was very excited. She had her cheerleading outfit and her yellowjacket face tatoo. She knew the cheers and she was ready to go. I'll post some pictures of it over the next day or two. She did a great job for only being in Kindergarten. I was very proud of her, as always.

I certainly don't encourage cheerleading. I've known very few cheerleaders that I actually respected (two). I tend to think the "sport" is for the flighty, energetic people that I typically don't associate with because they have way too much energy and way too little intelligence for me. However, I made a commitment many years ago to support her in whatever she wanted to do (as long as it was legal and moral). I'll stand by that even if she wants to be a cheerleader, but I'm sure she won't -- she's way to smart for that ;0)

DRY needlessly

DRY, don't repeat yourself, has become a battle cry to many in the programming profession. Wiping out all causes of spatial, temporal, and logical repetition is the aspiration of today's elite. However, zealotry has never suited me, and I tend to think that there exists good repitition as well as bad. Let's look at some examples:

First, Test-Driven Development is full of repetition. The tests and the code define the specification separately, but equally. Yes, you can make up all sorts of excuses for why there is duplication, but the fact remains that both the tests and the code are asserting the same thing.
Second, in Code Complete, Steve McConnell talks about the practice of using a function to check another function's work. For instance, if you are making some difficult calculations, you may wish to write a slow and steady function that you know works and then write a swift and dangerous function that you are unsure of. In debug mode you would run both functions and ensure the identity of the results.
Third, web programming often has client and server side validation of input parameters. Yes, I know you could write a control file and have both generated from that, but I seriously doubt that is a big enough win to justify the programming time involved. The duplication is accepted as useful.

In each of these cases, we're using repitition to enable a sort of "double-entry bookkeeping". We perform our work and then check our work to make sure everything balances out. The duplication is there for a reason, to ensure quality and correctness. The duplication that DRY is intended to eliminate is not there to support itself, but is instead needless. Think of it as a teepee. You have two sticks leaning different directions, supporting one another. There is repetition, you have two sticks instead of one, but they are working together and leaning on one another. This is the key, if you have duplication in your code, make sure the duplication is leaning in opposite directions.

Forty Things Wiki

I've created a wiki where I can post my thoughts and preliminary drafts of Forty Things Every Programmer Should Know...But Doesn't! I'm using phpWiki because it was a breeze to set up and should be just fine for what I intend to do. Please feel free to contribute to The Forty Things Wiki, but be sure to leave your name so I can give you credit!

Rake

Martin Fowler has a post on how to use Rake (a Make/Ant alternative written in Ruby). I'm going to give it a try sometime this week or next. I'll let you know how it works out.

40 Things Every Programmer Should Know

On my website I have started an outline of 40 Things Every Programmer Should Know...But Doesn't. There are eight categories consisting of 5 topics each. Obviously, most programmers will be familiar with some of the topics, and some will be familiar with many, but the hope is that there will be a few nuggets of interest lying in wait for the curious programmer willing to read my "book". The goal is not to have an in depth treatment of each topic, but a high level overview of what it is, when you would use it, and how and why it should make its way into your everyday programming life. I hope to complete one topic each week (or at least a rough draft). Keep checking in for progress reports.

Football pt ?

I have no idea what part I'm up to, but today I heard Dick Vermeil talk about Herm Edwards as someone who was an expert at his craft. For all the talk about software development being a craft, we now have talk of football also being a craft...the similarities continue.

Two Books

I read two books over the weekend, The Pragmatic Programmer by Andy Hunt and Dave Thomas and Programming Pearls by Jon Bently. Both were excellent books, though entirely different. The Pragmatic Programmer was about how to write robust systems and really began the craftsman movement. It discusses automated builds, regression tests, prototypes, estimation, source code control, text manipulation, code generation, and much more. It gives gems such as the correct answer when your boss asks how long it will take (the answer: "I'll get back to you."). It is about producing great software at all levels and is very similar in spirit to Steve McConnell's Code Complete, though it deals with design decisions much more.

Programming Pearls is about design in the small. It discusses how to choose the correct data structures and algorithms, how to determine complexity, and how to write efficient, fast code. If you didn't have a CS background, it would be an excellent book to give you a crash course. If you do have a CS background, it is an excellent in-depth view of small design decisions and is a timeless classic.

I definitely recommend both books and give them ***** out of *****!

Automated Build

Since I couldn't do much physically this weekend, I decided to practice what I preach and create an automated build for one of my projects. First, I'm embarrased that I hadn't done it sooner. Automated builds are one of the top three things that make a project successful. It is rather pathetic of me that I hadn't yet done it. However, I took the time this weekend and did a decent job of it. I hope that next time I can get it done early in the project instead of procrastinating like I have. In all fairness to myself, I have been working on some necessary infrastructure components so that the automated build can be easy to create and maintain, but I still should have got it done sooner. Anyway, it is done now and I can breathe easy!

Scooby dooby doo...

Where are you?

Well, I haven't been able to post too much as of late because I've had gall bladder surgery. It really isn't that bad anymore, it is an outpatient operation. They do it laproscopically, so you only have a few small incisions. I'm a little sore, but not too terribly. Hopefully, I will be back to blogging regularly again in the next day or two, at least by Monday. See you then!