[r2dnb]

While I have nothing against MBAs, this is a typical example of what people call MBAish / corporate BS and why managerial profiles have gained a bad reputation here. It looks smart on the surface but scrutiny exposes non-sense.

>Conversations around whiteboards between stakeholders creates value.

Why ? Are whiteboards magic ?

>Pair programming makes for lower defects and more reliable scheduling

Putting aside the fact that the benefits of pair programming as less consensual than what you seem to suggest, it can be done much more conveniently in a remote setup with a screenshare and a headset than by sharing a desk.

>Software is a design delivery operation.

So ?

>There was recent article on MS office space redesign to create more value.

Here we have the business case reference, always good to include one. The substantial remark is that once again this doesn't prove anything, the first reason being that "value" is extremely vague.

>Productivity is not per-keystroke

The art of looking like you are siding with the people you want to control while it is actually the opposite. If we go the bottom of the reasoning : value is not per keystroke, we therefore need to put employees in a room because their true value must be monitored to be appreciated. "Please understand, I really want to be able to appreciate your true value". Sounds a bit hypocrite to me.

>Personal productivity is almost a misnomer

One more slogan.

>I have been paid extra to kill projects that never should have started.

While I am the first to advocate careful planning and writing code last, as an entrepreneur, I consider it a crime to sabotage projects, because anyone who has ever created something, or started a project or a venture understands that creativity is almost Holy. Beyond the technical deliverables, projects trigger group (and market) dynamics and institutional learning that may be hard to reproduce later in time. For this reason, doers do not sabotage or kill projects, they rectify them. Sure there can be pure follies that need to be stopped ASAP to stop diverting valuable resources of the company, but my overall impression is that you have a more liberal approach to assessing what must be killed.

I respect arguments from both sides, but this comment is really representative of the crap filling most companies.

[pixl97]

>Why ? Are whiteboards magic ?

Anecdotally, for the amount of problems I have seen them solve in short order. Yes. They force an idea in the mind to become concrete and logically digestible to other members of the party. If you can't draw it in a manner that other people understand, you don't understand the idea well enough yourself. It is also free flowing. Ideas can be added to and removed quickly with an interface that almost all humans have been taught to use since a young age. It only contains 3 parts. The pen, the board, and the eraser. No software with far too many options to understand. No weird bugs that crash in the middle of a presentation. Pictographs can transcend language barriers. Software sellers will never create such a simple product, there is little value added reason to.

So yea, if not magical, far better than its competition in portraying ideas.

[r2dnb]

> They force an idea in the mind to become concrete and logically digestible to other members of the party.

You make a very valid point, what I was highlighting is that good communication can be achieved without whiteboards too.

I understand your underlying argument that whiteboards may constitute the best technology, but I also think there is a tacit convention at play here. People tacitly agree to communicate in a way that make whiteboards work. For there are many effective and fluid ways to iterate on ideas that do not involve live drawings or complex tech.

I know it for a fact as drawing my thoughts on a whiteboard has always been counter-natural to me. I can do it but I wouldn't say that it is necessary for good communication. It is just a communication choice that people make.

Everything that can be drawn clearly can also be written clearly (analogies, bullet point lists for flows, etc...). Not to say that diagrams are never helpful, but it may be a stretch to assume that drawings and whiteboards have an almost essential role.

[Chiba-City]

FWIW, spreadsheets are another remarkable group planning tool with an HDMI big screen. Many projects work forward against backwards constraint logic not always clear from day 1. Bugs made shallow with enough eyes applies early in projects. Even editing text documents of tables and lists around consensus concerning values of features and costs of risks is very useful. I have never had much need for any developer just typing against personal request. I always force stakeholders across roles and departments to sign their names to schedules and sign their names to ongoing weekly schedule adjustments. Every slip is caught ASAP including eyes on features bigger than schedule budget stomachs.

[Chiba-City]

Why don't you ask a question? I am not an MBA. I wrote Harvard's Ultrix manual, C on SunOS, Windows and Linux. I sat at whiteboards with Steve Crocker, Sunil Paul, Mark Pincus and Brad Cox across telecomms, finance, early Net and XML protocols and even early bioinformatics. Do you imagine we channel future visions from God out fingertips?

Let's eliminate some cases. I know some people work on entertainment software or short term content. Others work in departments "against management" for take home pay. I never care about those projects or those people working on them. My words do not apply there.

Interesting hardware is not virtual but involves complex supply chains. The same goes for productivity software interacting with the world already in motion. New training often costs more than new tools. DC folks making NASD broker registration reality are essential personnel in tight supply chain relationships. Any error on a Congressional Report can tumble decision makers into felonies or disrupt global commodity markets. Same goes for folks writing device drivers or porting libraries to new hardware. None of this is any app buried in app stores or Office Space TPS reports.

In such greenfield or release cycle projects the right team size and composition will get there first, avoid mistakes, clean up markets later cheapest or occupy profitable niches longest.

Software projects concern progress and reach and thus "pass the bus test." Nature is not kind to the shy. Individual problem are just problems. Anybody can consult from anywhere if they can make a living that way. Otherwise, nobody cares about homebodies. Never project socials problems or commute logistics as values or virtues. Skunkworks remains the model for focus and shared responsibility. Software is not the deliverable. Tools and answers are the deliverables.