The actual coding requires a great care and a non-failing talent for accuracy; it is labour-intensive and should therefore be postponed until you are as sure as sure can be that the program you are about to code is, indeed, the program you are aiming for. I know of one —very successful— software firm in which it is a rule of the house that for a one-year project coding is not allowed to start before the ninth month! In this organization they know that the eventual code is no more than the deposit of your understanding. When I told its director that my main concern in teaching students computing science was to train to think first and not to rush into coding, he just said “If you succeed in doing so, you are worth your weight in gold.” (I am not very heavy).
But apparently, many managers create havoc by discouraging thinking and urging their subordinates to “produce” code. Later they complain that 80 percent of their labour force is tied up with “program maintenance”, and blame software technology for that sorry state of affairs, instead of themselves. So much for the poor software manager. (All this is well-known, but occasionally needs to be said again.)
I wonder how things would be different in a world where this, rather than the Agile focus on delivering “business value” from day one, were the conventional industry wisdom.
I think that it requires balance. Agile/Scrum should die in a taint fire, but I’d be annoyed if someone told me that I had to spend 8 months in “design meetings” before I could write any code, build something, demo it, and get feedback on whether I’m digging at the spot marked X. I could get on board with “the business leaves the coders alone for 8 months, and they don’t commit to putting anything into production code until they know what the fuck they are doing”.
In other words, I don’t think that “thinking” and “coding” deserve to be separated into phases. Coding is a part of the thinking process (that doesn’t mean that all of the code must go into production) and thinking is part of the coding process, unless you’re doing rote work that ought to be automated.
The Agile vs. Waterfall is a red herring because it presumes business-driven engineering, which is an unpolishable turd. Waterfall replicates the sociology of a stable but dysfunctional hierarchical company: the work ripples down from level to level as each tier picks off the work it finds interesting: businessmen shout incoherent orders (with great emotion!) in January, designers come up with products in March, architects call the technical shots in May, programmers write the code in July, and ops people and QA support the code in its Eternal September. Agile replicates the sociology of an equally dysfunctional company without a stable hierarchy, which is even worse. In Waterfall, shit rolls downhill. In Agile, shit is flung from all directions. Personally, I prefer not to have shit thrown at or on me from any direction, which means that I don’t want to do business-driven engineering.
Waterfall is only better than Agile because it’s less aggressive. The Waterfall culture is one of seniority and complacency, which means that as long as you don’t piss anyone off, you can hide away and actually produce something. The Agile culture is the macho-subordinate culture that is constantly in your face. However, they’re both terrible and they both produce substandard software.
There isn’t one right feedback cycle. For some projects, weekly demos (or “iterations”) are appropriate. For others, monthly or yearly audit cycles are better. What is objectively true is that engineer-driven companies can produce quality software (not everything will be excellent, but the wins will pay for the losses) while business-driven engineering is doomed to failure.
I think you could make a decent case that most projects are not delivered now. Of course it’s hard to know for sure because undelivered projects have low visibility.
The organization I work for right now is very into Agile and part of the initial training is a bit of Agile brainwashing. They mean well by it and seem to genuinely believe in it. But my biggest complaint was that all of the Agile training inexperienced was just assumptions that sound reasonable but without evidence of to back them up. For example if you’re Agile you should fail fast, like you said, but nobody seems to be proving this is going on or what even fail fast means. For example, do people tend to actually double down faster in Agile?
His example of that company seems a lot like waterfall, but what he is advocating, thinking before coding, is not incompatible with the agile nor the waterfall approaches.
Software is actually very cheap in comparison to the value that it can create.
The problem, for professional managers, is that it exhibits a “control paradox”. For two hundred years, the value was created (and the riches made) through standardization, variance-reduction, and controlled process. This was concave work, insofar as the input-output curve flattened out quickly, and there was much less of a difference between excellence and mediocrity than between mediocrity and failure.
Modern software is convex. The input-output curve gets steeper as you go to the right; that is, the difference in payoff between failure and mediocrity is small (or nonexistent) but that between mediocrity and excellence is huge. The best people really are 10 or 100 times as productive as average engineers, not because they work harder (that’s impossible) but because they know what to work on, and because they avoid maintenance headaches by doing things right the first time.
Industrial management has a 200-year history of successfully adding value by reducing variance, because in a concave world, low variance and high output go together. In a convex world (as in software) it’s the opposite: the least variance is in the territory where you don’t want to be anyway. Convexity is a massive game-changer. It renders the old, control-based, management regime worse than useless; in fact, it becomes counterproductive.
Software’s control paradox is that, the less software development is controlled, the more value it produces. When you do business-driven engineering, the business loses. When engineers call the shots over their own work, everyone wins. The business gets annoyed, because the engineering organization is visibly only putting 50% of its steam into what the business needs, but what they’re missing is that they’re getting 50% of 10x instead of 100% of 0.25x.
The other issue is sociological and pertains to personnel. Software’s cost is largely labor, and professional managers (i.e. MBA types) like to solve problems by growing teams and throwing more people at problems. This is exacerbated by the fact that dick size is measured in MBA culture by number of reports, rather than by what the team actually did. So managing 100 mediocre programmers is more impressive than managing a team of 10 elite engineers who carried the organization. This creates an incentive for enterprise Javaization. No one doubts that a smart programmer can learn Haskell and be very productive quickly, but the question is, “How am I going to hire 50 engineers per month in Haskell?” Well, see, when you use Haskell, you rarely need a team of that size. It’s when you have the Java-shop/“Agile” culture that you start needing massive teams to accomplish even the smallest feats.
I disagree with most of what you write, michaelochurch, but I think that this single insight is worth slogging through all the nastiness:
Industrial management has a 200-year history of successfully adding value by reducing variance, because in a concave world, low variance and high output go together. In a convex world (as in software) it’s the opposite: the least variance is in the territory where you don’t want to be anyway.
I’m running a Haskell class and you can peruse the slides and videos here.
Learn You a Haskell is a decent beginner’s resource. After that, you can take on Beginning Haskell or the (excellent, but very dated) Real World Haskell.
It pains me to hear it is outdated. It is the one Haskell book I have. I always have trouble using the stuff like applicative and monads - I have a need to understand them but the types get messy quickly.
It’s still worth reading. Most of the core concepts haven’t changed very much; it’s just that a few libraries are different now, so you’ll want to brush up on those.
Our own @bitemyapp/Chris Allen’s guide has the best reference to Haskell resources (choices explained here). He’s done a lot of Haskell teaching and #haskell-beginners chat room on Freenode is very friendly.
@pushcx already mentioned my guide, but I’m also working on a book which is tested with new programmers – my coauthor herself is learning program in Haskell – no prior experience. It’s not free though and if you want free resources, then I do recommend my guide. If nothing else, I’d urge you to avoid LYAH/BH if you can help it. There are better alternatives to what I point towards in my guide, I mention them there and in my post that @pushcx linked.
Oh damn, your book looks promising, but it isn’t finished yet, and I don’t think I could fork of 60 dollars, being student has its draws. I’ll go ahead with the cis194 course in the free time.
I wonder how things would be different in a world where this, rather than the Agile focus on delivering “business value” from day one, were the conventional industry wisdom.
I think that it requires balance. Agile/Scrum should die in a taint fire, but I’d be annoyed if someone told me that I had to spend 8 months in “design meetings” before I could write any code, build something, demo it, and get feedback on whether I’m digging at the spot marked X. I could get on board with “the business leaves the coders alone for 8 months, and they don’t commit to putting anything into production code until they know what the fuck they are doing”.
In other words, I don’t think that “thinking” and “coding” deserve to be separated into phases. Coding is a part of the thinking process (that doesn’t mean that all of the code must go into production) and thinking is part of the coding process, unless you’re doing rote work that ought to be automated.
The Agile vs. Waterfall is a red herring because it presumes business-driven engineering, which is an unpolishable turd. Waterfall replicates the sociology of a stable but dysfunctional hierarchical company: the work ripples down from level to level as each tier picks off the work it finds interesting: businessmen shout incoherent orders (with great emotion!) in January, designers come up with products in March, architects call the technical shots in May, programmers write the code in July, and ops people and QA support the code in its Eternal September. Agile replicates the sociology of an equally dysfunctional company without a stable hierarchy, which is even worse. In Waterfall, shit rolls downhill. In Agile, shit is flung from all directions. Personally, I prefer not to have shit thrown at or on me from any direction, which means that I don’t want to do business-driven engineering.
Waterfall is only better than Agile because it’s less aggressive. The Waterfall culture is one of seniority and complacency, which means that as long as you don’t piss anyone off, you can hide away and actually produce something. The Agile culture is the macho-subordinate culture that is constantly in your face. However, they’re both terrible and they both produce substandard software.
There isn’t one right feedback cycle. For some projects, weekly demos (or “iterations”) are appropriate. For others, monthly or yearly audit cycles are better. What is objectively true is that engineer-driven companies can produce quality software (not everything will be excellent, but the wins will pay for the losses) while business-driven engineering is doomed to failure.
Is this answer a joke?
[Comment removed by author]
I think you could make a decent case that most projects are not delivered now. Of course it’s hard to know for sure because undelivered projects have low visibility.
[Comment removed by author]
The organization I work for right now is very into Agile and part of the initial training is a bit of Agile brainwashing. They mean well by it and seem to genuinely believe in it. But my biggest complaint was that all of the Agile training inexperienced was just assumptions that sound reasonable but without evidence of to back them up. For example if you’re Agile you should fail fast, like you said, but nobody seems to be proving this is going on or what even fail fast means. For example, do people tend to actually double down faster in Agile?
His example of that company seems a lot like waterfall, but what he is advocating, thinking before coding, is not incompatible with the agile nor the waterfall approaches.
Software is actually very cheap in comparison to the value that it can create.
The problem, for professional managers, is that it exhibits a “control paradox”. For two hundred years, the value was created (and the riches made) through standardization, variance-reduction, and controlled process. This was concave work, insofar as the input-output curve flattened out quickly, and there was much less of a difference between excellence and mediocrity than between mediocrity and failure.
Modern software is convex. The input-output curve gets steeper as you go to the right; that is, the difference in payoff between failure and mediocrity is small (or nonexistent) but that between mediocrity and excellence is huge. The best people really are 10 or 100 times as productive as average engineers, not because they work harder (that’s impossible) but because they know what to work on, and because they avoid maintenance headaches by doing things right the first time.
Industrial management has a 200-year history of successfully adding value by reducing variance, because in a concave world, low variance and high output go together. In a convex world (as in software) it’s the opposite: the least variance is in the territory where you don’t want to be anyway. Convexity is a massive game-changer. It renders the old, control-based, management regime worse than useless; in fact, it becomes counterproductive.
Software’s control paradox is that, the less software development is controlled, the more value it produces. When you do business-driven engineering, the business loses. When engineers call the shots over their own work, everyone wins. The business gets annoyed, because the engineering organization is visibly only putting 50% of its steam into what the business needs, but what they’re missing is that they’re getting 50% of 10x instead of 100% of 0.25x.
The other issue is sociological and pertains to personnel. Software’s cost is largely labor, and professional managers (i.e. MBA types) like to solve problems by growing teams and throwing more people at problems. This is exacerbated by the fact that dick size is measured in MBA culture by number of reports, rather than by what the team actually did. So managing 100 mediocre programmers is more impressive than managing a team of 10 elite engineers who carried the organization. This creates an incentive for enterprise Javaization. No one doubts that a smart programmer can learn Haskell and be very productive quickly, but the question is, “How am I going to hire 50 engineers per month in Haskell?” Well, see, when you use Haskell, you rarely need a team of that size. It’s when you have the Java-shop/“Agile” culture that you start needing massive teams to accomplish even the smallest feats.
I disagree with most of what you write, michaelochurch, but I think that this single insight is worth slogging through all the nastiness:
Completely tangential and off topic, but where should I start learning haskell?
I’m running a Haskell class and you can peruse the slides and videos here.
Learn You a Haskell is a decent beginner’s resource. After that, you can take on Beginning Haskell or the (excellent, but very dated) Real World Haskell.
Stephen Diehl’s “What I Wish I Knew When Learning Haskell” is good intermediate-level resource, and Stanford’s CS240h is good, too.
Hey I watched the first two lectures' slides and they are fantastic
It pains me to hear it is outdated. It is the one Haskell book I have. I always have trouble using the stuff like applicative and monads - I have a need to understand them but the types get messy quickly.
It’s still worth reading. Most of the core concepts haven’t changed very much; it’s just that a few libraries are different now, so you’ll want to brush up on those.
Our own @bitemyapp/Chris Allen’s guide has the best reference to Haskell resources (choices explained here). He’s done a lot of Haskell teaching and #haskell-beginners chat room on Freenode is very friendly.
@pushcx already mentioned my guide, but I’m also working on a book which is tested with new programmers – my coauthor herself is learning program in Haskell – no prior experience. It’s not free though and if you want free resources, then I do recommend my guide. If nothing else, I’d urge you to avoid LYAH/BH if you can help it. There are better alternatives to what I point towards in my guide, I mention them there and in my post that @pushcx linked.
Oh damn, your book looks promising, but it isn’t finished yet, and I don’t think I could fork of 60 dollars, being student has its draws. I’ll go ahead with the cis194 course in the free time.
We’ve been giving students discounts, email our support line from your school email address.