Dan Swearingen's Tech Stuff Blog

My colleague, Jeff Atwood also writes about this at his excellent Coding Horror.

No, Microsoft has not.

I have recent experience with software development in Vista (literally IN Vista). I work in a .NET shop but we did not build our Vista app in .NET. We used good old unmanaged Win32/C++.

Richard Grimes is a frequent contributor to many professional software journals and his Wrox books Beginning ATL COM Programming and Professional DCOM Programming saved my ass and made me look smart when I was building a DCOM based system working over satellite networking for Ford Motor Company in the late 90’s.

Richard has some great posts on .NET, Vista and specifically .NET and Vista. 

He shows, and laments, that there is virtually no .NET beyond the .NET runtime in Vista.  Further, he tracks that the amount of managed code within the .NET framework itself has measurably gone down with each release.

From this he concludes that Microsoft has lost confidence in .NET.

Grimes has missed the point. In building Vista, virtually every RECENT decision (over the last 18 months) has been driven by Microsoft ruthlessly pursuing stability and security. After umpteen intense code reviews this priority is now burned on my butt. At the same time Microsoft is also insisting on broad compatibility with existing applications and systems.

As Grimes demonstrates, the Microsoft OS (Vista) and application code base (Office, etc.) is almost entirely Win32/C/C++. What Grimes neglects to mention is that the Microsoft code base is also incredibly mature in terms of contained bug fixes and work-arounds.

Porting functionality to .NET would have directly increased security. However, porting any major function or system to .NET, while also faithfully replicating all the complicated legacy details contained is very expensive and error prone.

Microsoft does not have infinite resources and they cannot push hard on everything at the same time. Pursuing increased security and stability (in C/C++ those are directly and tightly coupled objectives) had the effect of reducing the goal of “more .NET” from a MUST into a “nice to have.”

The goal of a solid platform is worthy. Improving the security of the Windows platform is also a good idea. Looking at the history of Vista there is a clear pattern of tossing any new feature (WinFS, Avalon, …) if it cannot be guaranteed rock solid.

It’s gutsy that Microsoft has been willing to forgo attractive customer-facing features to pursue greater stability (which is only visible by a lack of instability…) and security (ditto).

It’s wimpy that they have not explained this well to the developer community.

The real issue Microsoft has to tackle is getting their marketing rhetoric in line with reality.

I do not entirely agree with Grimes but he represents a very important outside opinion that many eminent software developers share.

If Microsoft does not address the concerns of people like Grimes or the community he represents Microsoft could lose the “mindshare” race in the long run.

So with the February 2006 issue C/C++ Users Journal folded. Wil at Channel 9 reports that the note on his last issue read:

“For nearly 30 years, the C/C++ Users Journal has provided resources and information to serve the constantly evolving community of C and C++ developers.  [ ... blah, blah, blah ... ] What this means is that you are holding in your hands the last issue of the C/C++ Users Journal.  As a result, Dr. Dobb’s Journal, which has published C and C++ articles ranging from the days of Small-C to C++, will expand its coverage of these important programming languages even more.”

Okay so Dr. Dobbs will get bigger, right? The February 2006 issue of DDJ was 80 pages. The April 2006 issue, having absorbed all that CUJ content is now a whopping, wait for it, 60 pages.

My bet: Dr. Dobbs Journal will “Byte” it within a year.

In Dr. Dobbs and C/C++ Users Journal every month is a small ad for Gimpel Software’s PC-Lint where they present their “Bug of the Month” – a tough to find C/C++ bug that they use to demonstrate bugs that PC-Lint can help you find.

A coworker told me that the first thing he does when he gets a new issue of C/C++ Users Journal each month is flip through and find this ad and see if he can figure out the bug.

After years of doing anything but C++, for the last year I have been doing a Win32 application that will ship as part of Vista so I’ve started to work these puzzles too.

I admit, I usually have to actually code them up to find the issue but it really helps improve C/C++ skills. These also can make great interview questions.

Fortunately, when I get stuck, they give the answer on their site.

I just read a series of Kathy Sierra’s posts at the excellent Creating Passionate Users blog and I found a common theme in them: “when being stupid is the smart move”

Dignity is Deadly, Part Two - “When you evolve out of start-up mode and start worrying about being professional and dignified, you only lose capabilities.”

How to be an expert - “The only thing standing between you-as-amateur and you-as-expert is dedication.”

And Don’t forget square one… which was perhaps the most powerful. She discusses how you need to orbit back to the basics every now and then – but don’t spend too much time there.

I’ve been a software developer and engineering manager for a long time and to me, the key skill to moving forward is to constantly ask yourself: where am I still a beginner?

I know some people who seemingly do this constantly. They are also the severe early adopters (come to think about it, they are also often really annoying). I’m much more cyclical. I’ll go months “head down” on a project, just doing, and then finally pop up and look around.

And sigh.

Because I know it’s time to go be a beginner at something again.

Every time. Every single time, I find this process stressful. That’s because every time I forget that the LAST time I did this I thrashed around for no more than two days, got traction, and became competent at learning the new skill. Note I said learning the new skill, not competent at the skill. Once in the learning mode the stress is gone, I’m having fun. I feel young and vital again.

I strongly think that this makes the difference between a good developer and a great developer: good developers are competent and reliable. Great developers are willing to move away from the comfort zone of the place where they are competent and dare to be stupid: try a new skill where they are a beginner again.

I’m learning career advancement comes to those who blog. Stupid but true. Incredibly stupid but true. Spend less time actually working – spend more time writing about those 15 minutes you spent today actually being productive – and you will get promoted. It seems to really be a case of obvious over-enthusiasm being contagious.

That said, I am finding that blogging does bend your brain to organize how you communicate into cohesive messages.

I’ve been talking to lots of firms lately and I’m starting to believe that you can tell whether a company is serious about software and technology development by merely

1. Examining their org chart.

2. Asking them how willing they might be to changing their organization, especially if their org chart sucks.

This will have different ramifications depending on whether you want to join one of these companies as an employee or work with one of these companies as a consultant or consulting firm. In general, if you work at a company that fails the tests above (Sucks, refuses to change, respectively) you are probably Screwed (See especially Screwedness type #5).

If you want to consult at a company that fails the tests above, this company could be a gold mine. Assuming you are skilled and competent, they will need you just to be able to tie their own shoes. And they will never evolve into a company that does NOT need you. Ditto if you’re part of a consulting firm.

Let’s look at some concrete examples.

The Flat Model

This org chart is really popular these days. The little “legs” below the circles represent more direct reports so this plan involves 11 Lead developers with a total team size of 40-50.

This is the “flat” model. A.k.a. “we don’t need no stinking middle managers.” Here “middle managers” means anyone more senior than the many small team leads yet below the Director.

This org chart is effective if the development pace will be glacial or non-existent.

The other way this chart works is if each little project is completely un-coupled from all the other projects.

Little decoupled projects or slow maintenance mode == not a chart that says the company is serious about development.

Why? Because there’s insufficient cross team communication bandwidth to clear coordination problems. No “super leads”, no program managers.

When people are trying to build big projects fast, you run into situations where you need something from your neighbor. Something they had not planned on (because you had not planned on it). This means the leads having to stop and negotiate the interface issue.

A good middle manager delivers value by doing NOTHING but anticipating and clearing these team-to-team issues – keeping things moving forward. In the flat model there are no middle manager so this clearly assumes that the Director is doing all of it.

Having been the Director in a plan like this, I can assure you that once things get big and fast it is not possible for the director to have clear knowledge of what, exactly, is going on in all those teams.

It becomes management by fire control. The team on fire with the most problems gets the attention. Everyone else does without.

How do you solve a flat model?

Reorganize and create de-facto middle managers.

I was placed in charge of a project with a total team size of 105 developers, project managers, and graphics people spread across three companies and working at three different locations (LeapFrog Enterprises, Q1-2001).

I was successful only because management had flipped the bozo bit on the entire team. I could change anything I wanted — I could fire anyone I wanted to. The one person who needed firing was gone (the person who set up this monstrosity).

The “fix” is a post in and of itself but in summary: All I had to do was break the flat model.

The Silo

Here’s another org chart that screams: we are not building anything here.

This is a real situation. Here’s a senior developer with a small team reporting to a CIO. If the company is teeny tiny this doesn’t look that weird. But this is a real company that has over 800 employees and does over $650 million in sales each year. Think the CIO spends lots of quality time guiding that dev team?

I gave an example earlier of the massive train wreck I had to run. Once the dust settled (we shipped on time) and the consultants went home, I was left with a team that looked like:

This sort of worked. By the coy way I’ve drawn this I’ve carefully hidden that this is a big fat FLAT model. What problems did I have? Give you one guess:

It was impossible for me to really manage what was happening within and between all the teams because there is insufficient communication bandwidth available to clear coordination problems.

At this time we were no longer in a growth mode. I changed the chart by giving things away. I worked to have the lead of the Ops group promoted to be a peer Director of Operations and gave him the portion of the DB team that was really operations of the production database systems. He also got reporting and the QA group.

I kept the more senior development DBAs. This is what my group looked like after:

The cool thing is that it made my team much more focused on development and that’s what I enjoy the most anyway.

If this team had ever needed to grow (it never did) the way to do that would have been to promote one of the leads into a middle management role.