"Unless you can afford to have two or more competing teams solving the same problem, and c’mon, who would do that, you will never know."

So, the above metaphor is almost always impractical, and it's hard to tell what the alternative is to the one bricklayer you have.

The mythical man month never mentioned that. It mentioned multiple implementations of one architecture, but that was for hardware IIRC.

A better example is if A now comes back and says "yes, my wall's not as good, and I take longer, but now I'm only going to charge $4000", then you've got a bigger question - is it worth $1000 to you to get a higher quality wall that's done quicker? Or would you rather save the money and lose the time and build quality?

This more easily converts to a software example - do you pay a senior developer to develop your product quickly and well? Or do you save money by hiring a developer of lower skill, who will likely take longer and deliver a lower-quality product?

What if you have no background in software? If the lower-skill developer convinces you his work is better (even if it's not) you're going to go with him.

I'm more inclined to think that people would try to bargain hard with the Bricklayer B - "$500 in two hours is a good price for you, pal". After all the thought goes that even for that price B can erect a lot of walls in two weeks (which is A's single wall building time-span), and that's... only fair, right?

(in addition) Don't foul yourself that we live only under market-like laws of supply and demand, we're also social creatures that supposedly have to obey social norms. And the norms can be dictated.

There's pretty easy proof of this. You would spend weeks of time, $8000 in recruiting expenses, trying to get a web marketing manager who can increase your conversion rate.

But if there is a web site that you could allow to A/B test some change to your layout - that its operator somehow comes up with very quickly or even programmatically - you would not give them $5000 for a few minutes of work. It doesn't matter what the 'results' are, or if it's in escrow or tied to the results: you just wouldn't. You would prefer to spend weeks of time and double the money on a web marketer who doesn't work as well.

And for that reason, such sites just don't exist.

There is no place on the Internet you can pay someone $10K for 20 minutes of work, even if those 20 minutes are objectively quantifiably better than the results you would otherwise spend 6 months and $100K trying to achieve.

Human psychology just doesn't operate like that.

If you go to a web site that does A/B testing, you're going to get a set of instructions about how to install it on your site, and then it's up to you to figure out what changes you should try. You now how more work to do, and no better idea about what you should be trying.

If you really do have a way to replace a full-time marketing person with an automated web site, build it. It will be a gold mine.

Think through the pricing model of the hypothetical web site you propose in the last sentence - that is my point.

If a web site charged $500 and was very easy to implement, I could do it as an experiment and not lose much if it failed. If it succeeded, that web site could charge me again and again to keep doing it, and I would be happy to pay.

But if I have to spend $8000 and several weeks up front, I'm going to be very cautious. It doesn't matter if that money and time are spent hiring someone or purchasing and installing an automated tool.

"I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes" - I'm saying you wouldn't pay them to do so in line with what doing so would/should be 'worth' to you. There is no market to pay to revolutionize your marketing in 20 minutes, at a pricing that is based on what it should be worth for you to do so. Doesn't exist. You wouldn't pay it. Imagine what "revolutionaizing your marketing" means, image what "revolutionizing your marketing" would be worth to you - do you have that figure in mind? Now imagine paying that to someone for 20 minutes of their time. You wouldn't. Neither would anyone else. That market doesn't exist.

Markets can remain irrational longer than B can remain solvent.

I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.

Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.

If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work.

Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?

A decent manager should make themselves available to the team, but not interfere with the team unless something's going wrong, or appears to be going down the path of 'going wrong'. They should measure the team by their output, and use that to determine whether things are going wrong, or are about to go wrong.

Attempting to measure a team by their process makes the assumption that the manager is capable of understanding both the current process, and the maximally optimal process against which to compare the current process. It's far safer for both the manager and the team for the manager to avoid such endeavours, and instead measure the output itself against the optimal version of the output, because the output should meet business/product goals against which it can be assessed.

"Bricklayer A" was constantly rewarded for working hard. I was constantly reprimanded for wasting my time since I was deemed to have a much larger "potential," despite producing more output and with a higher quality than most others on my team.

This ended up with my leaving that team. So I can't agree that "bricklayer B" is always preferred, but I would say that a good manager would usually prefer that choice. Good managers are not easy to find.

With software, it's hard for people to tell that the finished product for Team B is as good as (or better than) that made by Team A, and therefore all they can look at is often effort. They see team A responding to alerts, alarms, production issues, etc, all night and weekend, and then see you cruise out at 5.

Sometimes comparing one piece of software to another piece of software is like comparing a garden shed to a skyscraper.

The wall example is similar to "Write a simple calculator capable of doing addition, substraction, division and multiplication". Anyone can tell if that software works as expected or not and have some idea if it's well done or not.

A similar comparison would be a team designing and building a fully functional house on a budget. In that example it's not easy at all to assert how well they are working, as happens in software development.

[1] only because I got the boards for wholesale price.

Does the software solve your problem? Then it's good software. If not, then what are you paying the programmers for, anyway?

I had a VP once who decreed that the "Productivity" rating on our annual review was to based on the average hours/week spent at work. To be deemed "Productive", a developer had to average 45+ hours/week. This had the effect of screwing over two subsets of developers: 1 - Those that were very efficient and got their work done in a reasonable amount of time. 2 - Those that didn't spend hours/week on timetracking, and just stuck on 40/week by default And rewarded those who were inefficient and took 50 hours to do 40 hours worth of work.

That is the problem. They can't see it that clearly. Everyone can see a brick wall. "Seeing" good code and from bad is not easy. So another proxy is used -- "apparent effort and time put into it".

So in reality when it comes to software, bricklayer A wins quite often.

Like the article said:

People huddled over screen debugging dangling pointer == GOOD.

Staying Friday night debugging deadlocks in threaded code == GOOD.

Lots of lines of code written == GOOD.

Get stuff done quicker, and then going home on time == BAD.

This is a failure of management, having not insight or understanding into how programming or product works and judging complex machinery and structure by the color of its blinking lights on the console or by the length of haircut of it creator.

Then I got a panicked call from the builders:

Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place.

The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all.

But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe.

In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA.

It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.

They may well have been paid in part already for work and you're left with nothing to show for it. In many cases they'll leave and find a new "victim" to work for.

I always thought "if this software thing doesn't work out, I'm gonna go be an electrician". I've now met lots of them making way more money than I am (and I'm well paid). Most of them basically have two or three customers, all of which are GC's. They've shown that they are:

- responsible (show up on time and in the right place)

- dependable (they get the work done on time and on budget)

- knowledgeable (they keep up to date with changes to code)

- respectful (they keep the job-site clean and work well with other subs)

In short, they're professionals in every sense of the word. In exchange they charge 3x what other tradesman charge. People are happy to pay it.

A friend of mine is an electrician. He did his apprenticeship with a guy who worked a lot with high end residential clients (i.e. stately homes — this was in England). He says the one of the most important things that he learned was to clean up after himself — which talks to your respectful point. It made him stand out amongst his peers, and is one of the factors that goes a long way towards repeat business and referrals.

1. Physically appearing at job site.

Being a software developer who just completed a substantial project (200 metres squared house on a difficult site) this was the most powerful thing I learned on the job. And now I apply it to my own code related problems. Who's in my crew? Where can I get new good crew? How do I manage dealing with cognitive overload by delegating back to other team members etc. I find the similarities/differences between software and construction crews fascinating.

I totally wouldn't have a problem paying top dollar for someone who is reliable and respectful of my time.

The more likely scenario in software is you get to day 45 with 90% of the wall built and the client asks you to hand over your key to the job site and stops taking your calls.

There's where most of the "half built walls" in my industry come.

Bricklaying machines where bricks go into a bucket and out the other end comes a horizontal wall. You could prefab this on the floor and then just put it up ... maybe, I don't know, I'm not a bricklayer.

Seems automated from the article.

Edit: As mentioned below, reading is fundamental, I should learn to do it sometime.

So it is a more ergonomic way of laying bricks; you're doing it upright, not crouched down. But you still have to lay them. You can't just throw a pile of bricks into it and get a road out without workers doing anything.

One thing that is hard to work around is where the interviewee must demonstrate their skill first hand (e.g. implement FizzBuzz followed by strcpy and a binary search.)

Many common interview questions are too indirect (Show me a certificate; Answer this trivia question about a Java API from 1997) or misguided attempts at personality tests (How many sewing machines are there in West Virginia) all of which one can prepare for without having the actual ability to do the job.

These kinds of questions can still work, as long as they have not yet made it into "How to succeed at interviews" type books. Or when the applicants you want to filter out cannot resist outing themselves even with training (e.g. "Tell me about a time when you have been wrong / publicly changed your opinion" will probably always be a useful filter.)

I think the big difference is that people know that pouring six flutes of champaign perfectly is hard. They've poured champaign before and they know they couldn't do it. The same goes for laying a wall. Shit, I don't know any management types that would even do thier own drywall. They know they'd screw it up. But, these same people just assume that software is easy. I just had an interview where the CEO asked me to figure out how to scrape an ugly website. I was given an hour to determine which toolkit to use, learn how to use it, and deliver a solution.

In software, it is very hard to measure productivity. Lines of code doesn't work. Function points? Nah.... Who is building whose contributions? Many of the nice things (reliability, ease of maintenance, flexibility, ease of testing) that require design expertise take years to see. Add to this that it is very hard to deeply understand complexity of problems, and if the source is the problem itself or the environment.

In the end, maybe the immediate manager knows all that's required, but if you get several layers up in the management chain, eventually you hit a non-technical boss. Unless you're at a software firm with a programmer-CEO. This is why it is important for technical folks to also be good communicators, and to "Work up" well.

Contrary to whatever you may think, you will not be able to build the next Microsoft, send a probe to mars, invent the next cancer drug, build a formula one car, or build the Pyramid of Giza or anything of such class working 2 hours a day, while relaxing away your time at a beach.

The world is full of examples of a Bill Gates sleeping below his office desk, Michelangelo falling from painting his way to exhaustion, or a John Carmack spending his time hacking in some isolated hotel.

The stories super successful people who work exceptionally hard and very real and are a common place in our culture.

I agree about quality and all that, but none of that will be sufficient for great tasks with meagerly efforts. Great things demand great effort.

I'm yet to hear of successful people who have become what they are by working just 2 hrs a day. Unless they just had a wild date with luck.

I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.

I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve.

Why are such people stuck doing some small time programming tasks.

In the actual case, the team Months could not connect the dots to see that the specific problem at hand, that involved two complex things, somehow had a much simpler solution. Their code, development time, etc. looked perfectly normal from an outsider's point of view. The code was taking 40 minutes per run. I was unaware of their work and coded the same thing independently. My code was five lines core in Matlab plus overheads, or about hundred lines total. It also ran in two minutes.

In short, no one was cheating. Nothing was amiss. Just that I could connect the dots and they could not. Had I not worked on the problem, I would not have figured either.

The issue is that in the normal course of lives, two people or teams are not asked to work on the same problem in isolation. So the difference in performance does not become evident at least in the short run. This is in spite of the amount of duplication of effort that often exists.

Now this does not imply that I could do this for every task, though I do have more examples just as profound. I can often understand complex problems better and faster than other people, and then can work through them faster. But if both sides understand the problem+solution equally well, I may actually be slower in implementing at least in the initial rounds. (This is because my breadth of knowledge across technology domains is often five-ten times broader than normal engineers, which also implies that I have less practice in each domain).

And yes, I am chasing some really big goals.

[1] www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693/

I would dispute the 'relatively accurate' assumption. My father works in construction and it's often the case that what me (as a non-construction worker) sees as a beautiful kitchen, he'll see as a nice-looking kitchen that's been cheaply made with quality and craftsmanship problems.

I would imagine that a bricklayer has a better chance of telling you whether a wall is likely to start cracking within five years than your average person off the street would, for example. You're assuming that non-bricklayers would know what to look for to assess the quality of the wall properly or that brick walls are so simple that any untrained person off the street could figure out what all those hidden factors are.

I think this is actually the exact same thinking mistake that people make when they assume that programming must be easy. It's seeing only what's on the surface and not realising there are deeper things (a previous poster mentioned 'hidden processes' when talking about laying down a hardwood floor, which is exactly what I mean here).

Brick walls have a very high level of observability. A non-bricklayer can look at a wall and tell if it fills the space it is supposed to fill, if the wall is obviously crooked or warped, if bricks are missing, and if mortar is missing between bricks. They can do all of this with very little expertise because they can physically inspect the wall and they have also seen many walls before and have internalized some norms for walls.

Compare this with a non-programmer's experience with software. All they see is the user interface, which is usually a very small part of the whole. Software has a very low level of observability.

Brick walls - typically - are also very simple systems when compared to software such as what is described in the original article. Lower complexity combined with a high level of visibility and broadly shared expectations means that lay people can make many more accurate judgements about a wall, the progress of a wall, the quality of work being done on a wall, etc. without being experts on wall building or brick laying.

This is not to take away from expert tradespeople or diminish their value. It's just a completely different situation which I believe was the intent of the original analogy.

I can think of few businesses where workers don't need downtime.

Bricklayer B has an idea that his ideas are better, but they aren't really.

Brick layer B is really bricklayer A.

Sure it isn't simple.

-- Bricklayer C: Tells you that you don't really need a brick wall, and should just stop heckling the people who go by.

There's even less observable work, and even more savings.