this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.
1) Industries don't learn; people do. We have a lot of turnover and growth in this industry, so a lot of new people. 2) Although there are high points of genius we may never reach again (Turing, etc), we are making progress. Software today can do things hardly imagined a few decades ago. 3) Part of how we make progress is to try "unlearning" things; throw out conventional wisdom and try something "crazy". Maybe it will fail the same way as before, or maybe this time it will work. Maybe the constraints that produced the conventional wisdom have changed. 4) People problems will always be hard, in every industry. Productivity is a people problem.
I am against a general ignorance of where the industry's been, which manifests as a refusal to learn basic software engineering concepts that are laid out in a book like the Mythical Man Month. Seems like every new medium (such as the web) starts with masses rallying around a figurehead who proclaims "this time it's different! We don't need any of that engineering stuff!" A few years later, they do.
This trend of anti-intellectualism is worrying. I doubt it's new -- Dijkstra had similar sentiments -- but the worst part is the developers who seem to enjoy being ignorant.
This is exactly why software engineering needs to professionalize.
I don't see developers always having more leverage than their business counterparts. Really, I'd love to see developers wholly accountable to their peers, along with some sort of entrance exam. I think the world at large would take developers a bit more seriously.
No sarcasm intended. You don't have to agree with SEI or IEEE, but the complaint was that there wasn't an organized body of knowledge. My response was to show that there is.
I'd be interested in knowing what you find so objectionable about SWEBOK.
This is not a fair analogy. Open heart surgery is a repetitive and well-defined procedure with clear goals and context. Software Engineering is a complex and creative endeavour where individual talent makes a big difference. There is no methodology that will help a mediocre writer produce a great novel. It takes skill and talent.
Actually, there are surprisingly large and persistent differences between hospitals in their complication rates for various surgeries. It is fueling a debate about how to evaluate them and how to promote the methodologies of the more effective places. Not really all that different from the software industry.
There's a difference between enterprise IT and other environments. For example, if you are a government tax department, your agenda is driven by legislative changes, and you want a fairly rigid process to ensure that things are done accurately and correctly.
You are lucky if you've never seen a methodology misused or misapplied. I have seen it many times, in my own work experience and in the failed projects I've taken over.
I'm not sure how you got the idea that I'm anti-intellectual. My intention was to express my own opinions and experience and start a discussion. I wasn't trying to wave anything away.
I absolutely agree that no software development methodology is guaranteed to work. However, there are certain things that one can do to reduce the chances of embarrassing development stalls, such as proper documentation, continuous unit testing, talking to the end user, and team communication.
Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.
I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers.
For example, we had coding standards requiring a comment explaining the contract for each method written, and this was enforced by version control on check-in. My colleagues were putting in comments like this:
/**
* Comment
*
* @param foo Parameter
* @param bar Another parameter
* @returns Something
*/
to avoid triggering the automated coding standards check, without actually revealing anything about the method they had written. I complained to the manager a few times, who did nothing, so I left.
That is too much doc for me, I wouldn't want to write it all either. Sounds like different people want to code a different amount of docs on their methods.. and should maybe be on different teams ;)
That sort of thing has an obvious problem. Take a fairly simple class:
class Shape
{
public:
void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
void SetColor(Color color);
};
What the methods do is bleeding obvious and the whole thing fits on a single screen where you can look at it. Now let's put all those comments in, what are they going to look like typically when inserting them is mandatory?
class Shape
{
public:
/**
* SetAbsolutePosition sets the Shape absolute position
*
* @param x The absolute X coordinate
* @param y The absolute Y coordinate
* @param units The units of the coordinates
* @returns Void
*/
void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetRelativePosition sets the Shape relative position
*
* @param x The relative X coordinate
* @param y The relative Y coordinate
* @param units The units of the coordinates
* @returns Void
*/
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetAbsoluteXPosition sets the Shape absolute X position
*
* @param x The X coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
/**
* SetAbsoluteYPosition sets the Shape absolute Y position
*
* @param y The Y coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetXRelativePosition sets the Shape relative X position
*
* @param x The relative X coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
/**
* SetYRelativePosition sets the Shape relative Y position
*
* @param x The relative Y coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetSize sets the width and height of the Shape
*
* @param height The length of the height
* @param width The length of the width
* @param units The units of the lengths
* @returns Void
*/
void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
/**
* SetHeight sets the height of the Shape
*
* @param height The length of the height
* @param units The units of the length
* @returns Void
*/
void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
/**
* SetWidth sets the width of the Shape
*
* @param width The length of the width
* @param units The units of the length
* @returns Void
*/
void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
/**
* SetColor sets the color of the Shape
*
* @param color The color to be set
* @returns Void
*/
void SetColor(Color color);
};
So now the class is eight times as long and you have to scroll eight times as much to find anything, in exchange for which you get a bunch of comments that tell you...
Unfortunately we all know that, but according to Lake Wobegon management style, not only are all our devs above average and all our code is error free, but also all our information is useful. All of it. Says so right there, on the motivational poster.
It doesn't apply to your example, but sometimes in maint mode the best part about boilerplate comments is being able to search for a synonym that appears in the prose comments but not in the code. In your example you could have some kind of distance calculating function that somehow neglects to mention Pythagorean theorem in the code itself, but very optimistically it would appear in the boilerplate, so I could grep for it.
While I understand the argument behind not commenting getters and setters, and it is quite valid, no it is not obvious what each of those methods do. For instance, what is the relative position relative to? Is the colour for the outline of the shape or the fill? Why do you have a width and height for a shape - does that mean it is a rectangle?
But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract. The contract can then be enforced by writing tests against it, and you know your code works when the tests pass.
It's very common to write the code first, write the tests against the code, and then write a comment against the code if you are lucky, but that doesn't actually prove anything, as the tests will be testing the implementation details, not the contract.
> But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract.
Which is kind of the point. You do need some kind of documentation for nontrivial methods. But requiring boilerplate documentation for everything encourages the opposite of that because it becomes "fill in the fields" rather than "say something useful." I mean let's say you're right and SetRelativePosition isn't clear about what it's relative to. Which of these is better?
/**
* SetRelativePosition sets the Shape relative position
*
* @param x The relative X coordinate
* @param y The relative Y coordinate
* @param units The units of the coordinates
* @returns Void
*/
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
-or-
/* SetRelativePosition: sets position relative to current position */
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
I'm not sure about Javadoc, but with Doxygen you do not need to put inline documentation immediately next to the code you are documenting. You could put all the documentation at the top of the file and the function declarations at the bottom. This makes it a little harder to maintain the docs while you maintain the code, but it does resolve one of your pain points.
"People suck and are lazy" is a known issue. It's been common knowledge for thousands of years now. So a methodology that doesn't work when practiced by sucky, lazy people is a methodology that doesn't work, full stop.
In my own anecdotal experience I would say the team matters way more than the methodology. I've been on teams that could have been (and were) repeatedly successful on projects that ranged widely from strict agile to strict waterfall. Every single time that team pumped out good quality software reasonably on time.
I've also been on teams that were not successful no matter what methodology they used. The team just wasn't cohesive, didn't have enough talent, and/or had poor leadership.
I've never been on a team that didn't have some manner of unnecessary ritual put on them by the management or client. I agree with your comment, and I would additionally add that a good team can go with the flow and work well within the context of most silly rituals.
1. Most important thing: do the users want the change. If not they sabotage and you fail. Users will never be happy.
2. Do you have enough experience and do they work well together, if not your mostly screwed. Right hand doesn't know what the left is doing. Takes too long to train new people usually.
3. Are estimates being treated as estimates or is date,team and scope being dictated from above? project triangle anyone. Stretch goals for managers mean long nights and weekends for the team and bonuses for other companies recruiters.
4. Has management been over sold on buzz words and marketing hype?
5. Is there some kind of incentive to come in under budget. So, much for quality.
So what this article is really saying (although reluctantly it seems) is that methodologies really do work, it's just not that they're the end-all and be-all. You need to have common vision and communication that works around the team's goals and personalities. Seems to be pretty common sense to me.
Well, his post is a bit inflammatory at first, but I sort of agree that processes sometimes get in the way, even the almighty Agile (big A) that some people like to subscribe to.
Ultimately, it's more about the people involved. Bad teams are going to find a way to screw themselves over no matter what process they use. Good teams don't need a rigid process since they'll just find a way to get stuff done no matter what.
"I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."
I suspect it's the author that has changed, not everyone else. It's probably a combination of a nostalgic bias combined with the author's increasing age making it harder to get on with a typical team of young whippersnappers.
I say this as someone who is over forty and regularly falling into the "things were better in my day" trap (although hopefully self-aware enough to see it).
I'm strongly against what he wants to revert back to, but I think he has a point. Many engineers are completely lacking in leadership and strategic capability, and fall prey to a cargo-cult, new-must-be-better, buzzword-chasing careerism no different from what we accuse managers of.
He's probably seen a few teams ruined by young megalomaniacs who want to put terms like Scrum and Kanban all over their resumes because they (being Clueless, in the MacLeod / Gervais sense of the word) think it's the ticket to the brass ring.
I agree, unfortunately (or fortunately), having stuff like that on your resume can translate to more dollars and happier wife; happier life. As I get older I wonder if Social Security will be there. In my lifetime pensions have gone away so it wouldn't surprise me to see SS go away. So I'd say load 'er up! Get all the terms and buzzwords you can on there.
None of it works because Waterfall and most forms of Agile both assume closed allocation, which is a bad assumption that wrecks everything. Closed allocation dooms you to prevailing mediocrity and process can only make that worse.
Most management and process exists to turn 1.0x developers into 1.2x (in theory) but turns the 10x into 3x or 2x or sometimes -2x. When you start enforcing process, closing up definitions of work, and take power away from engineers, you lose so much more off the top than you get from bringing up the bottom.
The problem is that very few executives actually want to create an inspiring place to work where people do their best. ("Fuck you, I've got mine.") They want incremental "improvements" (of questionable long-term value) on what already exists. This hand-wringing about process sounds a lot like early communism: it trudges along happily, inventing new structures, in complete ignorance of the human motivations around it.
In a nutshell: because by the time software companies start to look for some methodology silver bullet they are already hip-deep in trouble and no amount of 'process' will fix multiple years of bad hiring decisions, bad engineering and unrealistic expectations.
A short comment but the one I was looking for in this thread. People often forget the "People over Process" part of agile which implies no Methodology is going to be the answer. All you can hope for is to create the correct process (methodology) for the people you have at the time.
Trying to fit the people to the process is why software methodologies fail.
Try this thought experiment: Imagine two teams of programmers, working with identical requirements, schedules, and budgets, in the same environment, with the same language and development tools. One team uses waterfall/BDUF, the other uses agile techniques.
Problem is that with agile (as I understand and mildly practice it at least) you can't have "identical requirements", because you don't have full, complete and detailed requirements upfront.
I think there's a difference between having an initial set of requirements, and believing that those requirements are the requirements forever and ever, amen. Waterfall relies on the latter, while Agile assumes that they can and will change.
Both projects will be given the set of initial requirements. After all, if you don't have requirements, what the hell are you even doing? It's what happens when those requirements change that's the fun part.
Snarky, but frankly, there will be meetings very regularly with people who care & fund the project, as well as meetings within the engineering team to keep everyone abreast of what's going on.
The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.
That's a great solution when you understand the problem. Process is great when nobody can understand the problem. Windows is a great example of this, nobody at Microsoft really understands even 1/2 of what Windows does internally down at the code level. Now, how do you ensure a useful update comes out the door in 2015?
PS: Granted if you deal with less than 30 people process tends to be overrated.
I have no beef with process, I just find that the hooting and hollering over software methodology fairly asinine. Worse, the most stupid rules wind up getting embedded into company policy if you're not careful.
So, let's assume that different approaches work for different numbers of people (shocking).
How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done?
I would do it by having 1 person operate as a system integrator with responsibility for designing interfaces at the top level, then farming out the subcomponents to each subteam, until this reached the point of implementation. Lots of these things can be specified up front (front end! back end! database! integration with other systems! tooling! algorithms! shared utilities!) . As development ensued and new knowledge found, responsibilities would shift and new teams formed/older teams reassigned. Several key thoughts here: 1 person owns the vision of the system (call them the systems engineer), interfaces define interactions with other parts of the system, teams responsible for tightly cohesive components with loose coupling to other teams. Mind you, that's sort of Fred Brooks-ish, but why not? We haven't gotten too far from Psychology of Computer Programming in actual practice.
Its refreshing to see someone suggesting systems engineering as the solution to managing complex software projects. I have felt, and occasionally advocated, this for years. I'm actually surprised how little systems engineering methodology has penetrated the tech industry. Have CMMI and similar initiatives soured commercial enterprise on the idea?
Systems engineering is especially important when software is part of a larger multidiscipline project. All discussions here seem to focus on pure software projects.
> I'm actually surprised how little systems engineering methodology has penetrated the tech industry. Have CMMI and similar initiatives soured commercial enterprise on the idea?
I do not know. IMO, the CMMI-esque approach reeks of paperwork and micromanagement, and Agile approaches reek of lacking of planning. Both seem to be a bit problematic in their own way.
At any rate, would you mind providing some references & resources to read over for what you term systems engineering methodology? I am keen to understand other disciplines' approaches for getting engineering work done.
I'll start by directing you to the website of the membership society for systems engineers: http://www.incose.org Their products and publications section has some publicly-available documents discussing various topics.
The Systems Engineering Body of Knowledge (http://www.sebokwiki.org/) would also be a good place to start. Probably quite a bit of overlap with the INCOSE site, but better organized.
The move from labor-intensive, big-bang, monolithic deployments to fully automated, tested, non-event deployments has been a bigger positive change for me than any defined methodology or specific technology.
I tried to track the history of CI once[1] -- a similar practice may date back as far as the 60s at IBM. There are multiple sources indicating daily builds with tests at Microsoft from at least the early 90s (not quite CI but at the scale of the projects probably as close as practical at the time). Long before Agile became trendy in the 00's.
Pardon me prying, but what exactly is your experience?
I'm only asking because I've seen "in my experience" sermons delivered by fresh-out-of-college kids one too many times, and have become wary of the phrase.
"It’s common now for me to get involved in a project that seems to have no adult supervision". But my bigger problem is that the youth of today seem to have a much bigger ego than the youth of yesterday.
"Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion". Recently working with an off shore team, they called their tech lead literally "God". And he was pontificating procedures and styles left and right without understanding the core of the software first. He stopped when the product start to have big performances problems. One of the ones that I liked the most was his prohibition to use class indexers in C#, backed up by an example in Java.
IMO it's all about working with smart, motivated people who can work independently without the raging ego to cross borders to expand their computational Lebensraum. I've run remote projects with old friends over 3-5 years and it's gone spectacularly well.
In contrast, I've been on SCRUMed and Agiled projects where the resulting overhead on those who can already get work done without SCRUM Master Jar Jar's constant interruptions reduces them to people who quit within a few months.
But hey, acqui-hires rock and I can't imagine a better way to drive the talent out of a stable Fortune 500 company in order to take a chance at a startup than by driving them $%!@ing crazy and reducing their productivity to jack diddly. Ah the cycle of life...
That said, I see the use of methodologies where the talent is both junior and mediocre. But the former is better addressed with good mentoring (ha ha just joking - mentoring is for wimps, am I right? am I right?) and the latter by not hiring the mediocre in the first place (which means HR needs to be disrupted stat and since they hold all the cards they won't be - cycle of life again).
I agree mostly with the article. The most important thing about any team is its people and their individual & team dynamic. 2nd is motivation to make the project a success.
3rd or possibly lower is the methodology used. The methodology's main purpose in my opinion is to align everyone's working style to milestones, it doesnt reveal anything about whether the project will succeed, only how we will approach it.
Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. Our emotion comes into play when it comes to drive, motivation, hard work, creativity, and organization. Creating software requires motivation, creativity, organization, etc. Our emotion is behind software and we simply try to manage it with software development methodologies, but that's not enough.
How many people are over weight, who know that all you have to do is eat less, work out and then you will get in shape? It's that simple. Yet because of emotions, eating due to emotion, happy eating, sad eating, or poor self image many people don't get in shape. Likewise many students understand that all you have to do to get great grades is to avoid procrastinating, just start studying on time, study hard, study more, do most of the exercises in your text book, use multiple books and you are most likely to pass with high grades, yet lots of students put it off, poor will power, delayed gratification, it's more fun to goof off.
Same things apply to software, a lot of us know exactly what it takes to make good software, to spec it out, to plan a good architecture, to write good test units, to comment and document the code, to organize the process, to avoid over optimization, to avoid changing and adding lots of new features in the middle.
Yet, a lot of us don't do that, we start writing code before we even code before we spec out, because its exciting! Our emotions in play, we don't practice that delayed gratification of holding off and writing specs. We plan to throw away this prototype, but then somehow, it ends up being what everything is built on. We plan to refactor one day, but feature creep never allows for that. We know we ought to comment, but we understand the code now and don't, then 6 months later we are cussing and kicking the wall. Test units are boring, so we write as little of it as possible.
Until we take into account that programmers are humans, with emotions and different level of discipline, motivations and abilities our software development methodologies will keep to fail us for most projects.
Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven.
But there is nothing stopping you from incorporating emotion into your logical models.
I agree with your fundamental underlying opinion, but unfortunately it can't be reduce to a "programmer"'s problem. More often than not, it is to the whole organization you have to show "something" that is horribly coded but will convince someone from upper management than it is doable in a few months. And then you'll spend some years debugging the horrible mess you have created in the first place just to "show something". Pretty much anyone agree this is bad, but you can't sell a project by showing test coverage statistics.
The success of dieting programs is that people change their habits from unhealthy behaviors to healthy behaviors. The most successful ones are done in groups that offer emotional support in addition to health education.
The point of these methodologies is to help replace unhealthy development behaviors with healthier ones and to use groups that offer reinforcement of the healthy behavior as part of the process.
Of course, much like diets, not everyone is really going to "buy in" to the new "healthy" habits. They will drag their heels, whine, and generally continue their unhealthy behavior.
A big part of the lack of success of most diets is that the diets themselves change your emotional state. Not to mention that most actually encourage less healthy eating habits.
The American Heart Association for years recommended a low fat diet for heart health, when the studies they were using to justify this decision showed a higher overall mortality for people on low fat diets; they just died of fewer heart-related problems. (If I'm remembering correctly, there were a LOT more suicides in the low-fat group.)
The people who say "just eat less and exercise more!" are also completely full of it. It simply doesn't always work -- handled wrong it can lead to really bad emotional states brought on by the lack of food. Like the above example, you could end up with a lot more suicides, which are pretty bad for your health, no matter how you slice it. Presumably most people who make this claim are not fat or have never tried it, but it's frustrating to see it repeated over and over by people who exercise less than and eat more than a lot of "fat" people.
On the other hand, maybe the metaphor does work: We're recommending or enforcing practices when we really have no clue as to their efficacy. We don't always know what is healthy and what is unhealthy; we have guesses, but then we latch onto them like religion.
In my experience, a methodology should help a team get work done without having to think about the various steps/stages of the work.
Large corporations like to get everything down to a standard process (typically). A software development methodology lets them do exactly that; it promises a consistent process and (hopefully) quality.
In a way this works well - small firms innovate and come up with new methodologies which may at some point get to a tipping point where everybody wants a piece of the latest craze. Not everyone is in the business of questioning what works well or why - "if the competition is going Agile or setting up a DevOps team, then it must be good for us as well"
An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is largely impossible. Dynamic languages penchant for monkey (guerrilla) patching further exacerbates the problem.
Solutions to this are tough. My first suggestion would be to use languages which facilitate correctness, although it's usually at the expense of developer availability: the pool of engineers with experience and know-how in true FP is orders of magnitude smaller than more pervasive languages. My second thought is to further embrace math as the building block for non-trivial applications: mathematical proofs have real, quantifiable value in correctness. I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. This is even a tougher pitch than the first since most engineers don't recognize what they're doing as math at all - a big part of the problem. So many of us are doing by feel what has already been formally codified in other disciplines.
I'm aware that both require more (not necessarily formal) education than most engineers have pursued and makes it a difficult short-term pitch point for any company, but I think if we're serious about eliminating sources non-determinism from projects, it's important we address them directly.
I think that's one aspect of the problem, but the migration from make-do to mathematically rigorous code can be equally fraught with peril. While the code itself can be made predictable, and easy to reason around, the time estimates and project planning often cannot. There is never enough time to factor out all of the commonality, remove all of the unnecessary use of state, codify all the assumptions into data types, etc., so you have to pick your battles.
A programmer needs intuition of what the biggest, most effective improvements are on the code base, which allow them to get the most work done. They also need some ability to guess how much time it will take, so that they don't miss deadlines. No amount of static type analysis will fix that.
Ah, but that's a matter of design - except now we have strong constructs from which to consider our problem. We will never get away from developing the architecture of our system, which is cost dependent on how well understood the domain is. Ideally, that's where we should aim to move: problem specifications that render implementations rote. A lofty goal, I know, but within closer reach every day and possible in many environments already.
Part of the beauty of proof is that so long as it is correct, the individual lemmas are largely irrelevant: we don't necessarily need to remove commonality or statefulness. Of course, I'm purposefully glossing over extra-functional requirements on which, outside of big-O, we don't have a firm grasp.
I'm attempting to stay away from "effective" or "most work done" since they're ill defined and highly subjective but rather focus on measurable changes. I'd argue that, amortized, the upfront costs of better understanding the problem definition results in cost savings down the line, especially as it recedes into maintenance.
The dark side proof is that most mathematical problems are incredibly contrived. Taking a business requirement and translating it into known mathematical problems is harder than it sounds. Once you can do that, you're 90% of the way there, and people who can do that reliably are regarded as geniuses.
But most of the time, development is done without full understanding of the problem space. Usually, the problem doesn't become fully understood until you've already spent a good amount of time coding up your solution. If you wait until you fully understand the problem before starting, then you'll never start, because your brain simply can't comprehend the entire scope.
So instead, you get code bases full of sort-of well-factored code, but with lots of unwittingly reinvented wheels. This status is occasionally improved when somebody really smart happens to notice the commonality, and remembers a classic problem that it resembles, and manages to refactor the entire thing using the general solution. However, this almost never becomes apparent during the first revision.
"I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks."
I would like to learn more; do you have a specific example?
Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous mathematics; abstract algebra and formal logic have about the same amount of respect as basket weaving. Unfortunately, continuous math isn't particularly useful for software.
Two good examples from the Scala community would be Algebird[1] from Twitter which uses Monoids as a main abstraction and Spire[2], which might be the best numerical library out there and heavily rooted in Abstract Algebra.
I considered editing my other comment but decided instead to break it out.
There are a couple of complexities that your comment illustrates well:
First, continuous math _is_ available and immediately applicable today. The problem is that we often reason in and program to the implementation, not the abstraction - a subtle difference, but an important one. Not only that, but by reasoning in a flawed representation, we often miss important derivations that result in dramatic simplifications and reductions in the problem domain. I would also argue that we already do use continuous math regularly - for example, linear algebra, combinatorics, and set theor: most of us only know them as arrays, random, and SQL.
Secondly, not enough effort is made in formal education for applying 'pure' math to computer science. Some branches, such as linear algebra, have obvious implementations and analogies already available but others are quite a bit less clear - I fault this more on curriculum silos than an engineer's innate abilities. It's a learned skill that just isn't often taught.
As an electrical engineer who briefly flirted with computer engineering, I had 4 semesters of continuous math and 1 semester of discrete math[1]. I also had classes like linear systems and electromagnetics where I had to actually use continuous math heavily.
While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have found my Calculus/DiffEq foundation to be very valuable for my work with radar signal processing and NLP code, more so in the former because it was basically translating electrical engineering algorithms, formulas, and concepts into C. It is also important for any type of development that makes heavy use of geometry.
As a side note, I saw some of the bias you describe out of the more "pure" EEs I worked with when I first started. There was a strong bias against software engineers, particularly those who went the CS route, because they didn't understand the math and physics behind the hardware. Admittedly, some were clueless and probably should not have been writing software for multi-million dollar hardware[2]. Most were competent, though, and able to pick up the basics they needed to know when tutored for a bit.
[1] Which was actually titled "Discrete Mathematics", and was just covered basic set theory, combinatorics, and linear algebra.
[2] Like the one who added a reset routine that blindly opened power contacts on the UUT without verifying that the power supplies were off first. Fortunately, that was caught before they actually opened with hundreds of amps going through the bus.
As you say, continuous math (to my mind, calculus, diffeq, and linear algebra; anything involving reals) is necessary for some problem domains. But accounting is necessary for some problem domains as well. And molecular biology.[1]
But if I get worked up into a good froth, I can make a case that software development is applied formal logic or applied abstract algebra (or both). I don't believe you can do professional software development (in Weinberg's sense) without some serious discrete math, in the same way you can't do signal processing without calculus.
[1] If you've got something that mixes the three, let me know. It's probably something I should stay away from.
I must admit to ignorance of Weinberg's books and other writings. My interest is piqued now, though.
That said, based on your second statement nearly all scientific and engineering programming would not qualify as "professional software development". The code I worked on had little to no discrete math or formal logic in it. There was not an integer to be found save loop counters and array indices Do you not consider an (electrical engineer | mechanical engineer | physicist | molecular biologist) who can code and spends the vast majority of their time writing production code like this a professional software developer?
I find more problems when there's less focus placed on understanding the data, manually, first, before placing it into a process.
Methodologies don't make it any less important to find, connect and understand the data first, but it seems to happen way too much.
A methodology I see missing is when we developers obsessively focus on optimizing tooling and code, instead of obsessively finding and understanding the data first.
> rigorous studies of software development methodologies haven’t been done
A simple search proves this is false. Paired with author's other unsupported and stupendous claims I have to doubt the validity and worth of anything else author says.
Let me recommend you "Lean Software Strategies" book. It refers to many software development experiments and observations, some of them from Lockheed Martin. While the book does not claim to present the ultimate methodology, it draws on progress in other engineering disciplines to create a better, continuously improving process.
I did do a "simple search," and quite a few that weren't so simple. I've also read books on software development methodologies since the 1970s. I did link to the Cockburn paper, which surveys some studies and comes to the same conclusions I have. In the interest of brevity I didn't get into the well-known (anecdotal) studies from Weinberg, DeMarco, Yourdon, et al.
I know it's part of the fun to toss a firecracker over the wall, but if you are going to say that there ARE rigorous controlled studies please link to them, or at least post your "simple" search terms. If you want to point out which of my "unsupported" and "stupendous" claims are invalid and worthless I'm happy to learn from your experience. I tried to make it very clear that I am relating my own experience and drawing my own conclusions.
There are a lot of issues layered in here, a bunch of complexity that might not be obvious just by scanning the article.
Does a good team deliver solid, quality code? What if it's code the user doesn't want? Conversely, what if the team excels at delivering what the user wants, and they love it, but the code is so buggy that it only works 50% of the time? Would that be better than a solid app the user hates? (Probably yes)
Should a team working inside a large company deliver faster than the organization is able to accept change?
Just what is a good project, anyway? One in which we all had a good time and thought we did a great job? Or one in which the person paying us thought we were awesome?
No matter the criteria, everybody seems to agree that having good people is something like 70-80% of the secret. The big debate is what goes into that other 20-30%
ADD: An interesting thought experiment to play here is to posit that the team sucks -- wrong guys, wrong personalities, whatever. In that case, what would you want to happen? The answer to that should be an important part of whatever you want your process to be. Explicitly define your failure mode. (Because failure is still more often the norm than success in software development)
This would rather much be like a carpentry shop owner lamenting "why don't either electric circular saws OR handsaws work to make my mediocre workforce produce beautiful furniture without all of this wasted wood?"
First of all, creating beautiful furniture takes LOTS of time, as it rests in attention to detail and an uncompromising position towards quality. When you're uncompromising about quality, you require yourself to throw out, to waste, things that are of lesser quality.
Second of all, beginner, poorly trained, and dispassionate employees are never going to produce beautiful furniture. Mostly because of the above: they either lack the ability or the caring to have the attention to detail necessary to do great work.
And the best carpenters aren't going to come work for you unless you're willing to make it worth their time. Coming to work for you means they will have to do a lot more work in a much less comfortable environment than they are used to. Because the best carpenters have their own shop, their own tools, and work on their own time, because they love it. Going anywhere that is not their own setup is automatically worse for them.
It's the same thing in software: great software takes patience, it takes time, and it takes money to convince the best programmers that they should be spending their time on you rather than on themselves.
But at no point does any of that mean that, because Tool X can't magically turn your mediocre working into a stellar one, that means that Tool X is not worth studying. That is completely, 100% backwards. The master practitioner studies all tools, even the ones he or she doesn't like, at the very least to understand what is wrong with them and why they don't produce the results they want. A master carpenter might prefer a hand saw over an electric one because the electric saw chips the corners of the board too easily, or something. But he doesn't know that unless he's studied the electric saw.
You can't have "an absence of methodology" any more than a wood shop can have "an absence of tools". It has to be there. But they all have their pros and cons, and non of them has a pro that includes "makes men out of mice."
Nice analogy. Waste is normal in manufacturing. Cost-effective manufacturing doesn't necessarily mean that no wood is wasted. If you are focusing completely on wasted wood you might lose track of overall profitability or quality. (Or, you know, people not wanting to leave your shop ASAP)
200 comments
[ 614 ms ] story [ 708 ms ] threadErrrr....
This trend of anti-intellectualism is worrying. I doubt it's new -- Dijkstra had similar sentiments -- but the worst part is the developers who seem to enjoy being ignorant.
Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.
I don't see developers always having more leverage than their business counterparts. Really, I'd love to see developers wholly accountable to their peers, along with some sort of entrance exam. I think the world at large would take developers a bit more seriously.
That's everything we are complaining about right there on the index.
I'd be interested in knowing what you find so objectionable about SWEBOK.
I'm not sure how you got the idea that I'm anti-intellectual. My intention was to express my own opinions and experience and start a discussion. I wasn't trying to wave anything away.
For example, we had coding standards requiring a comment explaining the contract for each method written, and this was enforced by version control on check-in. My colleagues were putting in comments like this:
to avoid triggering the automated coding standards check, without actually revealing anything about the method they had written. I complained to the manager a few times, who did nothing, so I left.Remember, docs always lie
It doesn't apply to your example, but sometimes in maint mode the best part about boilerplate comments is being able to search for a synonym that appears in the prose comments but not in the code. In your example you could have some kind of distance calculating function that somehow neglects to mention Pythagorean theorem in the code itself, but very optimistically it would appear in the boilerplate, so I could grep for it.
But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract. The contract can then be enforced by writing tests against it, and you know your code works when the tests pass.
It's very common to write the code first, write the tests against the code, and then write a comment against the code if you are lucky, but that doesn't actually prove anything, as the tests will be testing the implementation details, not the contract.
Which is kind of the point. You do need some kind of documentation for nontrivial methods. But requiring boilerplate documentation for everything encourages the opposite of that because it becomes "fill in the fields" rather than "say something useful." I mean let's say you're right and SetRelativePosition isn't clear about what it's relative to. Which of these is better?
-or-The comments are most likely used to generate documentation, which can be very handy later.
I've also been on teams that were not successful no matter what methodology they used. The team just wasn't cohesive, didn't have enough talent, and/or had poor leadership.
2. Do you have enough experience and do they work well together, if not your mostly screwed. Right hand doesn't know what the left is doing. Takes too long to train new people usually.
3. Are estimates being treated as estimates or is date,team and scope being dictated from above? project triangle anyone. Stretch goals for managers mean long nights and weekends for the team and bonuses for other companies recruiters.
4. Has management been over sold on buzz words and marketing hype?
5. Is there some kind of incentive to come in under budget. So, much for quality.
All of the above can screw up a project quick.
Ultimately, it's more about the people involved. Bad teams are going to find a way to screw themselves over no matter what process they use. Good teams don't need a rigid process since they'll just find a way to get stuff done no matter what.
I suspect it's the author that has changed, not everyone else. It's probably a combination of a nostalgic bias combined with the author's increasing age making it harder to get on with a typical team of young whippersnappers.
I say this as someone who is over forty and regularly falling into the "things were better in my day" trap (although hopefully self-aware enough to see it).
He's probably seen a few teams ruined by young megalomaniacs who want to put terms like Scrum and Kanban all over their resumes because they (being Clueless, in the MacLeod / Gervais sense of the word) think it's the ticket to the brass ring.
Most management and process exists to turn 1.0x developers into 1.2x (in theory) but turns the 10x into 3x or 2x or sometimes -2x. When you start enforcing process, closing up definitions of work, and take power away from engineers, you lose so much more off the top than you get from bringing up the bottom.
The problem is that very few executives actually want to create an inspiring place to work where people do their best. ("Fuck you, I've got mine.") They want incremental "improvements" (of questionable long-term value) on what already exists. This hand-wringing about process sounds a lot like early communism: it trudges along happily, inventing new structures, in complete ignorance of the human motivations around it.
Trying to fit the people to the process is why software methodologies fail.
Problem is that with agile (as I understand and mildly practice it at least) you can't have "identical requirements", because you don't have full, complete and detailed requirements upfront.
Both projects will be given the set of initial requirements. After all, if you don't have requirements, what the hell are you even doing? It's what happens when those requirements change that's the fun part.
Here's my methodology.
* Figure out what the software does, what the business cares about, and what the users care about.
* Figure out what it kinda sorta needs to be under the covers
* Write prototypes of the technically gnarly bits.
* Flesh out the prototype and start writing integration/functional tests for the system.
* Ensure CI server is live, running integration/functional/unit tests and build documents on push.
* Primary work phase: code review, write tests, write code as you go along. Figure out if features are needed or not. Don't overdesign or underdesign.
* Document subsystems as they stabilize using comments and in-repo text files.
* End of project: everything is tested, documented, and working.
Rinse, repeat.
The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.
Agreed. I should have been more specifically snarky.
PS: Granted if you deal with less than 30 people process tends to be overrated.
So, let's assume that different approaches work for different numbers of people (shocking).
How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done?
I would do it by having 1 person operate as a system integrator with responsibility for designing interfaces at the top level, then farming out the subcomponents to each subteam, until this reached the point of implementation. Lots of these things can be specified up front (front end! back end! database! integration with other systems! tooling! algorithms! shared utilities!) . As development ensued and new knowledge found, responsibilities would shift and new teams formed/older teams reassigned. Several key thoughts here: 1 person owns the vision of the system (call them the systems engineer), interfaces define interactions with other parts of the system, teams responsible for tightly cohesive components with loose coupling to other teams. Mind you, that's sort of Fred Brooks-ish, but why not? We haven't gotten too far from Psychology of Computer Programming in actual practice.
Systems engineering is especially important when software is part of a larger multidiscipline project. All discussions here seem to focus on pure software projects.
I do not know. IMO, the CMMI-esque approach reeks of paperwork and micromanagement, and Agile approaches reek of lacking of planning. Both seem to be a bit problematic in their own way.
At any rate, would you mind providing some references & resources to read over for what you term systems engineering methodology? I am keen to understand other disciplines' approaches for getting engineering work done.
The Systems Engineering Body of Knowledge (http://www.sebokwiki.org/) would also be a good place to start. Probably quite a bit of overlap with the INCOSE site, but better organized.
OCW has a systems engineering course posted: http://ocw.mit.edu/courses/engineering-systems-division/esd-.... There are some lecture notes available, but unfortunately the materials are a little thin.
Carry on.
[1]: http://www.alittlemadness.com/2009/01/09/continuous-integrat...
I'm only asking because I've seen "in my experience" sermons delivered by fresh-out-of-college kids one too many times, and have become wary of the phrase.
"It’s common now for me to get involved in a project that seems to have no adult supervision". But my bigger problem is that the youth of today seem to have a much bigger ego than the youth of yesterday.
"Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion". Recently working with an off shore team, they called their tech lead literally "God". And he was pontificating procedures and styles left and right without understanding the core of the software first. He stopped when the product start to have big performances problems. One of the ones that I liked the most was his prohibition to use class indexers in C#, backed up by an example in Java.
In contrast, I've been on SCRUMed and Agiled projects where the resulting overhead on those who can already get work done without SCRUM Master Jar Jar's constant interruptions reduces them to people who quit within a few months.
But hey, acqui-hires rock and I can't imagine a better way to drive the talent out of a stable Fortune 500 company in order to take a chance at a startup than by driving them $%!@ing crazy and reducing their productivity to jack diddly. Ah the cycle of life...
That said, I see the use of methodologies where the talent is both junior and mediocre. But the former is better addressed with good mentoring (ha ha just joking - mentoring is for wimps, am I right? am I right?) and the latter by not hiring the mediocre in the first place (which means HR needs to be disrupted stat and since they hold all the cards they won't be - cycle of life again).
3rd or possibly lower is the methodology used. The methodology's main purpose in my opinion is to align everyone's working style to milestones, it doesnt reveal anything about whether the project will succeed, only how we will approach it.
--Mike Tyson
How many people are over weight, who know that all you have to do is eat less, work out and then you will get in shape? It's that simple. Yet because of emotions, eating due to emotion, happy eating, sad eating, or poor self image many people don't get in shape. Likewise many students understand that all you have to do to get great grades is to avoid procrastinating, just start studying on time, study hard, study more, do most of the exercises in your text book, use multiple books and you are most likely to pass with high grades, yet lots of students put it off, poor will power, delayed gratification, it's more fun to goof off.
Same things apply to software, a lot of us know exactly what it takes to make good software, to spec it out, to plan a good architecture, to write good test units, to comment and document the code, to organize the process, to avoid over optimization, to avoid changing and adding lots of new features in the middle.
Yet, a lot of us don't do that, we start writing code before we even code before we spec out, because its exciting! Our emotions in play, we don't practice that delayed gratification of holding off and writing specs. We plan to throw away this prototype, but then somehow, it ends up being what everything is built on. We plan to refactor one day, but feature creep never allows for that. We know we ought to comment, but we understand the code now and don't, then 6 months later we are cussing and kicking the wall. Test units are boring, so we write as little of it as possible.
Until we take into account that programmers are humans, with emotions and different level of discipline, motivations and abilities our software development methodologies will keep to fail us for most projects.
Just my opinion.
But there is nothing stopping you from incorporating emotion into your logical models.
(I've been told that I have been using "yeah, good luck with that" too frequently lately, so I'm trying to branch out into different phrasing.)
The point of these methodologies is to help replace unhealthy development behaviors with healthier ones and to use groups that offer reinforcement of the healthy behavior as part of the process.
Of course, much like diets, not everyone is really going to "buy in" to the new "healthy" habits. They will drag their heels, whine, and generally continue their unhealthy behavior.
A big part of the lack of success of most diets is that the diets themselves change your emotional state. Not to mention that most actually encourage less healthy eating habits.
The American Heart Association for years recommended a low fat diet for heart health, when the studies they were using to justify this decision showed a higher overall mortality for people on low fat diets; they just died of fewer heart-related problems. (If I'm remembering correctly, there were a LOT more suicides in the low-fat group.)
The people who say "just eat less and exercise more!" are also completely full of it. It simply doesn't always work -- handled wrong it can lead to really bad emotional states brought on by the lack of food. Like the above example, you could end up with a lot more suicides, which are pretty bad for your health, no matter how you slice it. Presumably most people who make this claim are not fat or have never tried it, but it's frustrating to see it repeated over and over by people who exercise less than and eat more than a lot of "fat" people.
On the other hand, maybe the metaphor does work: We're recommending or enforcing practices when we really have no clue as to their efficacy. We don't always know what is healthy and what is unhealthy; we have guesses, but then we latch onto them like religion.
Large corporations like to get everything down to a standard process (typically). A software development methodology lets them do exactly that; it promises a consistent process and (hopefully) quality.
In a way this works well - small firms innovate and come up with new methodologies which may at some point get to a tipping point where everybody wants a piece of the latest craze. Not everyone is in the business of questioning what works well or why - "if the competition is going Agile or setting up a DevOps team, then it must be good for us as well"
Solutions to this are tough. My first suggestion would be to use languages which facilitate correctness, although it's usually at the expense of developer availability: the pool of engineers with experience and know-how in true FP is orders of magnitude smaller than more pervasive languages. My second thought is to further embrace math as the building block for non-trivial applications: mathematical proofs have real, quantifiable value in correctness. I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. This is even a tougher pitch than the first since most engineers don't recognize what they're doing as math at all - a big part of the problem. So many of us are doing by feel what has already been formally codified in other disciplines.
I'm aware that both require more (not necessarily formal) education than most engineers have pursued and makes it a difficult short-term pitch point for any company, but I think if we're serious about eliminating sources non-determinism from projects, it's important we address them directly.
A programmer needs intuition of what the biggest, most effective improvements are on the code base, which allow them to get the most work done. They also need some ability to guess how much time it will take, so that they don't miss deadlines. No amount of static type analysis will fix that.
Part of the beauty of proof is that so long as it is correct, the individual lemmas are largely irrelevant: we don't necessarily need to remove commonality or statefulness. Of course, I'm purposefully glossing over extra-functional requirements on which, outside of big-O, we don't have a firm grasp.
I'm attempting to stay away from "effective" or "most work done" since they're ill defined and highly subjective but rather focus on measurable changes. I'd argue that, amortized, the upfront costs of better understanding the problem definition results in cost savings down the line, especially as it recedes into maintenance.
But most of the time, development is done without full understanding of the problem space. Usually, the problem doesn't become fully understood until you've already spent a good amount of time coding up your solution. If you wait until you fully understand the problem before starting, then you'll never start, because your brain simply can't comprehend the entire scope.
So instead, you get code bases full of sort-of well-factored code, but with lots of unwittingly reinvented wheels. This status is occasionally improved when somebody really smart happens to notice the commonality, and remembers a classic problem that it resembles, and manages to refactor the entire thing using the general solution. However, this almost never becomes apparent during the first revision.
I would like to learn more; do you have a specific example?
Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous mathematics; abstract algebra and formal logic have about the same amount of respect as basket weaving. Unfortunately, continuous math isn't particularly useful for software.
1. https://github.com/twitter/algebird 2. https://github.com/non/spire
There are a couple of complexities that your comment illustrates well:
First, continuous math _is_ available and immediately applicable today. The problem is that we often reason in and program to the implementation, not the abstraction - a subtle difference, but an important one. Not only that, but by reasoning in a flawed representation, we often miss important derivations that result in dramatic simplifications and reductions in the problem domain. I would also argue that we already do use continuous math regularly - for example, linear algebra, combinatorics, and set theor: most of us only know them as arrays, random, and SQL.
Secondly, not enough effort is made in formal education for applying 'pure' math to computer science. Some branches, such as linear algebra, have obvious implementations and analogies already available but others are quite a bit less clear - I fault this more on curriculum silos than an engineer's innate abilities. It's a learned skill that just isn't often taught.
While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have found my Calculus/DiffEq foundation to be very valuable for my work with radar signal processing and NLP code, more so in the former because it was basically translating electrical engineering algorithms, formulas, and concepts into C. It is also important for any type of development that makes heavy use of geometry.
As a side note, I saw some of the bias you describe out of the more "pure" EEs I worked with when I first started. There was a strong bias against software engineers, particularly those who went the CS route, because they didn't understand the math and physics behind the hardware. Admittedly, some were clueless and probably should not have been writing software for multi-million dollar hardware[2]. Most were competent, though, and able to pick up the basics they needed to know when tutored for a bit.
[1] Which was actually titled "Discrete Mathematics", and was just covered basic set theory, combinatorics, and linear algebra. [2] Like the one who added a reset routine that blindly opened power contacts on the UUT without verifying that the power supplies were off first. Fortunately, that was caught before they actually opened with hundreds of amps going through the bus.
But if I get worked up into a good froth, I can make a case that software development is applied formal logic or applied abstract algebra (or both). I don't believe you can do professional software development (in Weinberg's sense) without some serious discrete math, in the same way you can't do signal processing without calculus.
[1] If you've got something that mixes the three, let me know. It's probably something I should stay away from.
That said, based on your second statement nearly all scientific and engineering programming would not qualify as "professional software development". The code I worked on had little to no discrete math or formal logic in it. There was not an integer to be found save loop counters and array indices Do you not consider an (electrical engineer | mechanical engineer | physicist | molecular biologist) who can code and spends the vast majority of their time writing production code like this a professional software developer?
I find more problems when there's less focus placed on understanding the data, manually, first, before placing it into a process.
Methodologies don't make it any less important to find, connect and understand the data first, but it seems to happen way too much.
A methodology I see missing is when we developers obsessively focus on optimizing tooling and code, instead of obsessively finding and understanding the data first.
A simple search proves this is false. Paired with author's other unsupported and stupendous claims I have to doubt the validity and worth of anything else author says.
http://www.amazon.com/Lean-Software-Strategies-Techniques-De...
I know it's part of the fun to toss a firecracker over the wall, but if you are going to say that there ARE rigorous controlled studies please link to them, or at least post your "simple" search terms. If you want to point out which of my "unsupported" and "stupendous" claims are invalid and worthless I'm happy to learn from your experience. I tried to make it very clear that I am relating my own experience and drawing my own conclusions.
Does a good team deliver solid, quality code? What if it's code the user doesn't want? Conversely, what if the team excels at delivering what the user wants, and they love it, but the code is so buggy that it only works 50% of the time? Would that be better than a solid app the user hates? (Probably yes)
Should a team working inside a large company deliver faster than the organization is able to accept change?
Just what is a good project, anyway? One in which we all had a good time and thought we did a great job? Or one in which the person paying us thought we were awesome?
No matter the criteria, everybody seems to agree that having good people is something like 70-80% of the secret. The big debate is what goes into that other 20-30%
ADD: An interesting thought experiment to play here is to posit that the team sucks -- wrong guys, wrong personalities, whatever. In that case, what would you want to happen? The answer to that should be an important part of whatever you want your process to be. Explicitly define your failure mode. (Because failure is still more often the norm than success in software development)
First of all, creating beautiful furniture takes LOTS of time, as it rests in attention to detail and an uncompromising position towards quality. When you're uncompromising about quality, you require yourself to throw out, to waste, things that are of lesser quality.
Second of all, beginner, poorly trained, and dispassionate employees are never going to produce beautiful furniture. Mostly because of the above: they either lack the ability or the caring to have the attention to detail necessary to do great work.
And the best carpenters aren't going to come work for you unless you're willing to make it worth their time. Coming to work for you means they will have to do a lot more work in a much less comfortable environment than they are used to. Because the best carpenters have their own shop, their own tools, and work on their own time, because they love it. Going anywhere that is not their own setup is automatically worse for them.
It's the same thing in software: great software takes patience, it takes time, and it takes money to convince the best programmers that they should be spending their time on you rather than on themselves.
But at no point does any of that mean that, because Tool X can't magically turn your mediocre working into a stellar one, that means that Tool X is not worth studying. That is completely, 100% backwards. The master practitioner studies all tools, even the ones he or she doesn't like, at the very least to understand what is wrong with them and why they don't produce the results they want. A master carpenter might prefer a hand saw over an electric one because the electric saw chips the corners of the board too easily, or something. But he doesn't know that unless he's studied the electric saw.
You can't have "an absence of methodology" any more than a wood shop can have "an absence of tools". It has to be there. But they all have their pros and cons, and non of them has a pro that includes "makes men out of mice."