Dan Swearingen's Tech Stuff Blog

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.

Kathy Sierra talks about what’s on her coffee table.

For me, it’s more like: what’s piled next to my bed.

I collect a big stack until it becomes structurally unstable (i.e. I trip over it getting up in the morning) and then put away books that I’m not actually reading. Books here have a half life of about one month — after three months there’s really 100% turnover.

PC Gamer is great for keeping up with not games but HARDWARE. There are game reviews in it too.

The Narrow Gauge and Short Line Gazette is a model train magazine.

Game Developer – please just take me outside and shoot me if magazines like Game Developer become something I like. I got a free subscription and I’m still paying too much.

Model Railroader – see Narrow Gauge and Short Line Gazette above.

WIRED magazine – I don’t know why I bother with it anymore. Maybe because $12/year feels like nothing? Usually the magazine does too. Ok, that’s too harsh. WIRED would not seem bad if you had never seen the first few years of it when it really felt new and felt part of the whole Internet THING.

Altered Carbon – a collegue who left the company I’m working with left this for me. GREAT book. Thanks Rob!

Ace of Spies – we saw the mini-series about this guy on A&E DVD recently and during the first 25 years of the 1900′s this guy was EVERYWHERE important. Often referred to as the prototype for James Bond although in real life Sidney Reilly looked like a skinny Peter Lorre.

Code Names – a run down on everything known about current US military and intelligence operational code names and what we are doing and where we are doing it. Note that this book is really a big fat LIST. It’s not really something you read. Slightly scary.

Framework Design Guidelines – kind of a combination coding standard that includes WHY you do things. Mostly very good stuff.

.NET Components, 2nd Ed. The .NET 2.0 version of Juval Löwey’s excellent book. If you’ve ever met Juval or attended one of his talks, you know that he is pretty much a “My Way or you’re even dumber than you look” kind of guy. However, I find a lot of great stuff in this book (and his lectures). Highly recommended.

Programming Microsoft Windows Forms – this is Petzold’s .NET 2.0 continuation of his earlier Programming Windows with C#. The book’s main point is that with three rocks, a C# compilier and a pointed stick you can build any WinForms app. I think what he’s responding to is certainly something I’m seeing in my work. Mainly that developers are becoming adept users of Visual Studio’s code generators without enough fundamental understanding of what the generated code really does. This is a really good book.

Game Development Essentials – this book is really “history of the game industry in 20 pages” followed by 400 pages about what the org chart of a game company looks like with pretty pictures. Leave this book at a truck stop rest room so people have something dry to stand on when they pee.

Web Database Applications – A nice (slightly out of date) description of the MP part of the LAMP web platform.

A First Course in String Theory – once upon a time I was an astro-physicist. No, really. String theory was something we argued about (I never liked it). So far this textbook doesn’t kick my ass until chapter 4 (Nonrelativistic Strings – at first glance that should include what you tie your shoes with until you are travelling REALLY fast…). I grab a book like this every other year or so so I can suffer much the same way some people swim the English channel while pulling their entire extended family behind in a barge.

Did anyone notice this? The cover of the March DDJ said INTELLIGENT SYSTEMS. There was an editorial about AI and everything.

However, there was not a single article about AI or intelligent systems in the entire issue. WTF? Here’s a listing of articles (http://www.ddj.com/articles/2006/0603/) at their website. 

There were some good articles in that issue but what happened? Is Dr. Dobbs Journal going to BYTE the dust too?

My dad had been a serious microcomputer hobbyist (they didn’t call them PCs yet) in the SF Bay Area in the mid-late 70’s. Although he was fascinated by these early machines, he was more the musician/writer type and was mechanical, but not really technical.

My step-mother and father did some teaching at the San Francisco Community Music Center in the Mission district (Him: recorder, her: modern dance). Through one of the faculty, Jef Raskin, dad did some tech-writing work for a budding company Jef was working with making a new micro computer. They were working out of someone’s garage in Brisbane. I remember playing Pong on it and the case was made out of wood with a sloped front in the same basic shape that would later become the Apple II.

The first micro in our house was a prototype PolyMorphic Poly-88 S-100 bus system (the S-100 was a semi successful early microcomputer standard).  How prototype? Most the boards were not soldered components on PC boards but wire-wrapped construction. He paid something like $1,500 for it and another $3,000 for a 16 KB memory board.

The Poly 88 was a dead chunk of metal until you loaded the “OS” which was really an early BASIC. The load was by cassette and you had to have the volume on the cassette deck just right or the load would fail 15 minutes into its 20 minute cycle.

My father got a government job in the Middle East that lasted from the late 70’s to the early 80’s. My sister and I would go out to visit a couple times a year. We would typically fly out from San Francisco, spend the night in London, and continue on to the mid-east the next day. We were kids but traveled alone on maroon official passports and had done the trip many times.

When the IBM PC came out it was very expensive. You could easily spend anywhere from $3,000 to $10,000 on a set up. Instead of the IBM PC, dad had a CP/M “Big Board” Z-80 based system he built from a kit. It could run MS BASIC, VisiCalc, and an early WordStar – I’ll talk about that machine in another post. I played with that machine all the time I could. I wanted a machine of my own for the ten months a year I was away from dad’s machine.

On one “out bound” trip I saw one of the new Sinclair ZX-81 kits for sale at a shop in Heathrow Airport. I talked my dad into giving me the money for the computer (I’m thinking it was 65 Pounds?) and picked up the kit on my way home. I had taken electronics classes and knew how to solder digital circuits so I slapped that baby together and had it working in no time.

Dad’s Big Board had 64K (the max you could have with a Z-80). The ZX-81 had 2K. 2048 whole bytes of RAM. This article is more than 2K.

I quickly learned that I could write big (well, bigger) programs if I kept the variable names short. Better still if I used line numbers starting with 1 instead of 10 (saved two whole bytes!).

Later, after Timex had brought out the Sinclair line under their name, I bought the 16K RAM pack and then I was really cooking – real variable names, four-digit line numbers.

A problem was that my Sinclair was an early model and the power supply was not well filtered under the additional current load of the 16K RAM pack so cassette recordings (Writes) of program dumps had a 60 Hz hum in them so loud that listening to the recording later (Reads) was difficult and error prone.

At the time there was an active community of hobbyist and small businesses dedicated to the ZX-80/81. I have two issues of a newsletter “Syntax ZX80” and several photocopied articles from “Sinclair User.” Microcomputing and Byte also regularly featured ZX-80/81 articles.

If you were a Real Programmer, there was machine code, and books to support you.

I see that these days there are ZX-81 emulators available for anyone who wants to suffer like a pioneer.

I have to admit I put this in the same category as running a marathon.

Barefoot.

On broken glass.

While I learned quite a bit about programming from those early machines, I do not miss working on them.

Some sites on the ZX-81:
ZX81 Home Page
ZX-81 Download Page