Hordes Of Novices(blog.8thlight.com)
blog.8thlight.com
Hordes Of Novices
http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovices.html
32 comments
> And what's the alternative?
I think the author gives an alternative in the form of his pilot training; intense training before being allowed to write code (= a proper and full education, instead of a course), and pair programming (= co-pilot) with an experienced or non-novice pilot (developer).
The big corporate world doesn't tend to agree with this though, two people doing one job seems like a waste of money and time to a lot of managers that don't know any better.
I think the author gives an alternative in the form of his pilot training; intense training before being allowed to write code (= a proper and full education, instead of a course), and pair programming (= co-pilot) with an experienced or non-novice pilot (developer).
The big corporate world doesn't tend to agree with this though, two people doing one job seems like a waste of money and time to a lot of managers that don't know any better.
Do you think this is the solution? Would it work in any environment? Start-up for instance?
One could argue that training a programmer should be like training a doctor - once you get over the initial hurdle of getting into Medical school, it's all about a long period of learning and mentorship.
My impression is that great programmers can come from unlikely sources. It's ok to cast a wider net for people, when the worst thing that happens is that they're more skilled for their efforts.
One could argue that training a programmer should be like training a doctor - once you get over the initial hurdle of getting into Medical school, it's all about a long period of learning and mentorship.
My impression is that great programmers can come from unlikely sources. It's ok to cast a wider net for people, when the worst thing that happens is that they're more skilled for their efforts.
If one doctor can transplant a heart in ten hours, can ten nurses transplant that heart in one hour? Can a hundred nursing assistants transplant that heart in six minutes? Can six hundred hospital receptionists transplant that heart in one minute?
The real question is: Could the doctor do the transplant without any nurses? Could the nurses help the doctor without the receptionists?
The real question is: Could the doctor do the transplant without any nurses? Could the nurses help the doctor without the receptionists?
I agree very much. All honest work is honorable work and it takes all kinds to make the world go 'round.
But I also think the organizational distinction between receptionists, nurses and doctors is helpful in making a hospital function. I must admit I sometimes feel that missing in the software industry.
Given time we tend to organize into functional units where people know who's good at what and how to contribute, but it's sort of like if everybody was hired into a hospital with the same job description and then had to informally hash out who should play doctor and who should be the receptionist...
But I also think the organizational distinction between receptionists, nurses and doctors is helpful in making a hospital function. I must admit I sometimes feel that missing in the software industry.
Given time we tend to organize into functional units where people know who's good at what and how to contribute, but it's sort of like if everybody was hired into a hospital with the same job description and then had to informally hash out who should play doctor and who should be the receptionist...
If I wanted to be pedantic I'd say that you'd really want a heart transplant done by a surgeon, not a doctor...
That said, I think the real questions is: who is Robert Martin, self-described uber-hacker, that his opinions should be taken so seriously? What has he written?
That said, I think the real questions is: who is Robert Martin, self-described uber-hacker, that his opinions should be taken so seriously? What has he written?
To expand on that a bit, I should mention that this question came up at a software craftsmanship meetup, after Martin had given a talk in Cambridge. (Incidentally, people who had seen him speak had been very disappointed.) The only answers to "Who is Uncle Bob?" seemed to be "He's very old" and "He wrote a book". Given his schtick is to be a sage figure of comparable stature to, say, Don Knuth or Brian Kernighan, I don't think that's good enough.
(I missed Martin's talk because it clashed with one by Herman Hauser. Industry pioneer vs methodology salesman wasn't much of a contest for me.)
I the interests of full disclosure, I should probably mention that I've had an encounter with another Martin (Micah) from 8th Light (see http://forums.pragprog.com/forums/62/topics/2753) - nice kid but I wouldn't want him writing code that I needed to rely on.
(I missed Martin's talk because it clashed with one by Herman Hauser. Industry pioneer vs methodology salesman wasn't much of a contest for me.)
I the interests of full disclosure, I should probably mention that I've had an encounter with another Martin (Micah) from 8th Light (see http://forums.pragprog.com/forums/62/topics/2753) - nice kid but I wouldn't want him writing code that I needed to rely on.
Dear Mr Newton. My memory of the Cambridge event a few years back is rather different from what you report. As I recall, the room was packed, the reception was enthusiastic, as was the applause; and the folks who talked with me later were excited and congratulatory. I don't know who you talked to, but -- perhaps it's best not to report on things that you didn't attend.
As for Micah, my son, he runs a very successful software development company of 60 or so developers who specialize in extremely high quality software. He maintains very high standards for the developers who work for him. Every one of them practices TDD as well as many other practices that we've found to be beneficial. The result has been a steady stream of very satisfied customers and repeat business. Those customers would likely disagree with you about the reliability of his code; and the code of his employees. But then, I don't imagine your comment was based on any actual knowledge of his code. Perhaps it's best not to report on things you haven't seen.
As for Micah, my son, he runs a very successful software development company of 60 or so developers who specialize in extremely high quality software. He maintains very high standards for the developers who work for him. Every one of them practices TDD as well as many other practices that we've found to be beneficial. The result has been a steady stream of very satisfied customers and repeat business. Those customers would likely disagree with you about the reliability of his code; and the code of his employees. But then, I don't imagine your comment was based on any actual knowledge of his code. Perhaps it's best not to report on things you haven't seen.
One last point. People like Donald Knuth and Brian Kernighan are heroes of mine. I would not sully their names by comparing them with the likes of me.
I find the described interaction problematic from an agile standpoint: "People and interactions over processes and tools" - and then, they agree to give a lecture on TDD? You're describing literally shoving a process down the throats of unwilling programmers.
I'm not an agile expert, but it seems to me they should have refused such an arrangement, and plainly say: "Right now, you don't use an agile methodology. Us giving a lecture to your guys won't change that, it will simply be a waste of your money. You can rent from us an agile coach for minimum 6 months, and she will try to transition you to an agile methodology. This isn't a single decision you make and then 'bam, you're agile' - this affects hiring, you might even have to let go of programmers who won't play along. Don't pay us for a lecture that will simply anger your employees and achieve nothing."
Regardless of the usual agile vs. waterfall debates, what they did sounds to me very far from the principles of being agile.
I'm not an agile expert, but it seems to me they should have refused such an arrangement, and plainly say: "Right now, you don't use an agile methodology. Us giving a lecture to your guys won't change that, it will simply be a waste of your money. You can rent from us an agile coach for minimum 6 months, and she will try to transition you to an agile methodology. This isn't a single decision you make and then 'bam, you're agile' - this affects hiring, you might even have to let go of programmers who won't play along. Don't pay us for a lecture that will simply anger your employees and achieve nothing."
Regardless of the usual agile vs. waterfall debates, what they did sounds to me very far from the principles of being agile.
Nimi, the agile manifesto does not say "People and Interactions _instead_ of processes and tools". Indeed, the preamble to the manifesto is quite specific that we think processes and tools are good things. It's just that people and interactions should take precedence.
In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.
In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.
Thanks for replying.
Could you elaborate on your stance? Obviously, being agile doesn't do away with processes and tools. But giving a lecture on TDD to unwilling programmers seems to guarantee the "people and interactions" part of the equation will be unsatisfactory. There's also the question (at least in my mind) of how this should be viewed in terms of customer collaboration - without attending that lecture, it seems to me that there's no collaboration here, robin2's employer pre-ordered something useless, and that's what they got. Where am I wrong?
Obviously, teaching TDD in a collaborative and positive environment, and making sure the students are capable and willing to practice TDD would be very much "agile".
Just in case that's not clear: I'm sincerely asking that with humility, there's not a doubt in my mind you have a much better grasp of what agile means - you defined it...
Could you elaborate on your stance? Obviously, being agile doesn't do away with processes and tools. But giving a lecture on TDD to unwilling programmers seems to guarantee the "people and interactions" part of the equation will be unsatisfactory. There's also the question (at least in my mind) of how this should be viewed in terms of customer collaboration - without attending that lecture, it seems to me that there's no collaboration here, robin2's employer pre-ordered something useless, and that's what they got. Where am I wrong?
Obviously, teaching TDD in a collaborative and positive environment, and making sure the students are capable and willing to practice TDD would be very much "agile".
Just in case that's not clear: I'm sincerely asking that with humility, there's not a doubt in my mind you have a much better grasp of what agile means - you defined it...
Nimi, to be clear, I did not define agile; I simply collaborated in the effort that defined it.
In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.
In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.
I see, thanks for clarifying. Actually sounds similar to a course I'm teaching at my university - supposed to be an "advanced C course for EE" (whatever that means), I threw in a bit of "intro to agile", what little I can try to teach from my limited experience (obviously Object Mentor is/was much better equipped for doing that type of thing). In a few weeks the reflection documents will be due and I'll know if it worked... :-)
In this case, I don't think the company can be blamed. As I recall, it hadn't asked for TDD training, it had asked for C++ training. So if anyone should be blamed it would be ObjectMentor for (a) hearing this as "introduction to object orientation", and (b) sending someone with rusty C++ skills.
At the time of that course, Micah was supporting a very large C++ application, and had been for some years. Were his skills rusty? I rather doubt it.
In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?
In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?
That's what I meant - even if your employer asked for TDD training, ObjectMentor should have objected on the grounds that it will achieve nothing.
Well, ObjectMentor got paid, someone at the company got to tick a box to say that developers had been given appropriate training, and we got a break from real work.
Corporate training is an odd business, it has to be said.
Corporate training is an odd business, it has to be said.
Did this just blow straight past ad hominem to character assassination?!! This is the first time a post on HN has turned my stomach.
I don't know Mr. Newton's beef. I found the virulence of his posts rather surprising since they were entirely off topic, and an attempt to make the topic about me, personally, rather than about what I wrote. Perhaps he will clarify.
OK, challenge accepted. I've only just noticed that this thread continued, and to be honest I doubt anyone will read this - but seeing as Mr Martin's responses aren't unreasonable I think they deserve an answer. I'll have to collect my thoughts, so more later...
[Part II]
In another comment, Mr Martin suggests that something like a guild system might be an appropriate for software development, and I'm assuming that 8th Light's interest in apprenticeship reflects this line of thinking. This sort of talk is interesting, but runs the risk of sliding toward sub William Morris sentimentality, which would be a shame. As it happens, I know a small amount of economic history that might possibly be helpful.
It's fairly obvious that the sort of industrial capitalism exemplified by, say, a 19th Century Lancashire cotton mill doesn't apply very well to software development. The capital costs involved in doing software development can, in extreme, be merely those of a laptop computer and an internet connection. This, I suspect, is what encourages the "rock star" model, which says that if you have some modicum of programming skill, the right idea, the right attitude and a bit of luck, then you too could become rich beyond the dreams of avarice. (See also http://quantumprogress.files.wordpress.com/2011/06/screen-sh...) Whilst I don't personally find this terribly attractive, is has a certain amount of logic to it.
Similarly, if we are to look to an earlier model - master craftsmen and apprentices - then we should look at the forces at play, rather than just the image.
One thing to understand about a traditional apprenticeship is that it was a serious commitment. As I recall, a typical period of indenture was seven years. Some of the reasons were economic; I'll give a couple of them.
One reason not to rush towards the status of master craftsman was that obtaining that obtaining the tools of ones trade could itself take a very long time. As I recall, the most extreme example of this was with blacksmiths, who would typically have to wait to inherit the equipment they needed.
Another reason for the length of indenture was to do with the fact that an apprentice wasn't an employee, and wasn't paid for his labour, but that the master had an obligation to house and feed him. So the cost of the apprentice's labour stayed the same, even though the value of the labour increased as the apprentice gained in experience. Hence it was, in this respect, in the masters' self-interest to have the indenture last a long time.
Both the points I've just mentioned suggest a disanalogy more than anything else, and don't really do much to illuminate the contemporary situation. I've got a final point which I think is more telling.
As I said, an apprentice wasn't an employee, and an indenture agreement was a mutual bond that carried obligations quite unlike those of a modern employer/employee relation. One of these was that a master couldn't let apprentices go when there wasn't sufficient revenue-generating work to keep them occupied. Even in lean years, a master was still responsible for the apprentices' keep, and they might be kept busy with, e.g., building up inventory in anticipation of future need. (This is, incidentally, one reason given for the decline of this system: masters preferred the flexibility of having hired hands that they only paid for when they needed them.)
This contrasts very strongly with a modern corporation that has an obsession with every quarter's bottom line, and a hire-and-fire attitude towards its employees. Quite apart from the effect of this on morale, it potentially impacts skill acquisition: it is a dicey proposition for an employee to invest in skills that tie them to their current employers since they never know when they might have to look for something new.
I don't how the tension between the requirements of craft and commercial reality can best be resolved. I don't know if it can be resolved at all. That's OK. Open questions are the interesting ones.
Anyway, I've said my thing now. Over and out.
In another comment, Mr Martin suggests that something like a guild system might be an appropriate for software development, and I'm assuming that 8th Light's interest in apprenticeship reflects this line of thinking. This sort of talk is interesting, but runs the risk of sliding toward sub William Morris sentimentality, which would be a shame. As it happens, I know a small amount of economic history that might possibly be helpful.
It's fairly obvious that the sort of industrial capitalism exemplified by, say, a 19th Century Lancashire cotton mill doesn't apply very well to software development. The capital costs involved in doing software development can, in extreme, be merely those of a laptop computer and an internet connection. This, I suspect, is what encourages the "rock star" model, which says that if you have some modicum of programming skill, the right idea, the right attitude and a bit of luck, then you too could become rich beyond the dreams of avarice. (See also http://quantumprogress.files.wordpress.com/2011/06/screen-sh...) Whilst I don't personally find this terribly attractive, is has a certain amount of logic to it.
Similarly, if we are to look to an earlier model - master craftsmen and apprentices - then we should look at the forces at play, rather than just the image.
One thing to understand about a traditional apprenticeship is that it was a serious commitment. As I recall, a typical period of indenture was seven years. Some of the reasons were economic; I'll give a couple of them.
One reason not to rush towards the status of master craftsman was that obtaining that obtaining the tools of ones trade could itself take a very long time. As I recall, the most extreme example of this was with blacksmiths, who would typically have to wait to inherit the equipment they needed.
Another reason for the length of indenture was to do with the fact that an apprentice wasn't an employee, and wasn't paid for his labour, but that the master had an obligation to house and feed him. So the cost of the apprentice's labour stayed the same, even though the value of the labour increased as the apprentice gained in experience. Hence it was, in this respect, in the masters' self-interest to have the indenture last a long time.
Both the points I've just mentioned suggest a disanalogy more than anything else, and don't really do much to illuminate the contemporary situation. I've got a final point which I think is more telling.
As I said, an apprentice wasn't an employee, and an indenture agreement was a mutual bond that carried obligations quite unlike those of a modern employer/employee relation. One of these was that a master couldn't let apprentices go when there wasn't sufficient revenue-generating work to keep them occupied. Even in lean years, a master was still responsible for the apprentices' keep, and they might be kept busy with, e.g., building up inventory in anticipation of future need. (This is, incidentally, one reason given for the decline of this system: masters preferred the flexibility of having hired hands that they only paid for when they needed them.)
This contrasts very strongly with a modern corporation that has an obsession with every quarter's bottom line, and a hire-and-fire attitude towards its employees. Quite apart from the effect of this on morale, it potentially impacts skill acquisition: it is a dicey proposition for an employee to invest in skills that tie them to their current employers since they never know when they might have to look for something new.
I don't how the tension between the requirements of craft and commercial reality can best be resolved. I don't know if it can be resolved at all. That's OK. Open questions are the interesting ones.
Anyway, I've said my thing now. Over and out.
OK. Here goes nothing.
I had a conversation with someone I know about what I wrote, and why I wrote it. Their comment was that without giving any explanation as to why I wrote what I did, the whole thing just comes across as arrogant and mean spirited. I think it's worse than that: the cumulative effect of a number of different remarks, that I had thought of as distinct, is one of a sustained, vindictive attack on the whole Martin clan and the horse they rode in on. Now, I could say "that wasn't my intention", but it doesn't matter very much what my intention was: how it comes across is how it comes across, and for that I can only apologize.
More specifically, I have absolutely no reason to doubt that both Martins have lots of genuinely satisfied customers. Also, with regard to the thread I linked to, now that I've done a spot of freelance consulting myself (even introducing the concept of unit testing to a client) I'd say that "consultancy" is a fairly broad concept. I'm still uncomfortable about the "hired gun" aspect of it, but I now know enough about that world to know that I know very little, and so shouldn't be making sweeping statements about it.
I'm aware that what I wrote shows me in a bad light. I could trying to clarify points badly explained, dispel unintended implications, and backtrack on exaggerations and plain mistakes. But I won't. The light is going to get worse in two paragraphs' time.
[Incidentally, you know when someone says "I'm sorry, but..." and you think to yourself "That's not really an apology"? I'm about to do something like that. I'm sorry. But I'll try to redeem myself in some other way later on.]
Mr Martin said that my tone was virulent. Even allowing for my not having explained myself very well (or at all) this is certainly true. I didn't notice at first how much anger there was behind it. It took me by surprise. What's behind the anger? What's always behind anger: pain. For some reason, something hit me in a really, really sore spot. Even though on the internet no-one can hear you scream, they can read the stupid things you write in the heat of the moment. So, yeah, there's a large element of lashing out here: but if I elaborate a little bit, perhaps some relevance to the matter in hand might become apparent.
Here's a key bit of context: the other year I was on a project in which I may have made mistakes that put lives in danger.
When I say "may" I don't doubt that I made mistakes. The nature of the work, the poor usability of the tools being used, meant that even a momentary lapse in concentration could easily result in a slip which would either go undetected or necessitate time-consuming rework. Problems tended to snowball. It would have been difficult work, even if it weren't being done in a noisy office. My uncertainty regards the extent to which the data we were dealing with was safety critical, and how much further scrutiny it would be subject to: I heard different things from different people, and don't know who to believe. (The truth can be a complex thing to unravel, even without people acting to cover their backs or to save face.)
The real mistake I made, however, came long before, and isn't one that can be easily blamed on circumstances. For a long period before I had become fatalist, and for the sake of a quiet life I'd been too cowardly to push back against things that I could see were wrong. It got to the point where it just seemed par for the course that I ended up with a computer that seized up on a daily basis.
Extreme stress is an interesting experience, although one that's probably best enjoyed when you're not doing anything important at the time. (Mind you, the warnings you get on packs of beta blockers are scary, especially for an asthmatic like me.) A complicating factor at this time was a bout of naive optimism: that if everyone were less coy about problems at work then it would be possible to tackle the root causes, that one should be the change one wishes to see, etc. Crazy, I know. Anyway, I fear I'm digressing.
I'm trying to bring this around to my first beef with Mr Martin, which isn't really a beef with Mr Martin so much as the habit of devaluing "home grown" knowledge in favour of that which is "bought in" (books, training courses, certification, even blog posts). The thing is that, as far as I can work out, some lessons have to be learned the hard way: even when a piece of second-hand wisdom is true, it does no good without a visceral understanding as to why it is true. There's not much point in a company being well informed about good practice if it then says, in effect: "none of the software for this project is being delivered to the customer, therefore the normal principles of software engineering don't apply."
The other thing I wanted to say about bought in knowledge is that there is always more to be had, and always someone trying to sell it. (At times it can seem akin to the situation with theories in social psychology, as described by Michael Billig when he said that "psychologists treat theories like toothbrushes: no one would wish to use someone else's.") In my experience, constantly chopping and changing the ways things are done, in pursuit of some best way, can be enormously destructive. Much better to have a reasonably good way, and stick to it, perhaps tweaking it now and again in the light of experience. Apart from anything else, tacit knowledge gets embedded in the way things are done, and can only really be picked up through doing: its "knowing how" rather than "knowing that", skill rather than information.
This sort of brings me on to why I didn't address Mr Martin's essay. The reason was that it seemed rather lightweight: the diagnosis was, as far as I could see, that if people didn't sufficiently value software development expertise then it was because no-one had pointed out to them that software development is a skilled activity and that the skills can't be acquired instantly. Surely, I thought, it is too obvious to be worth saying. Moreover, when someone says something to obvious to be worth saying, surely they must have an ulterior motive. Hence, in my ire, I assumed Mr Martin must be trotting out easy pieces as a form of self-promotion.
The are a number of grounds for saying that this was stupid of me, but one of them is that what Mr Martin said wasn't, in fact, too obvious to be worth saying. Sometimes things are worth saying even when they are obvious: what is obvious to one person isn't obvious to others. Moreover, I should have known this from my own experience. (There is a software company I know where the - now retired - HR manager said that "technical competencies" were relatively unimportant, as anything technical could be picked up on a short training course.)
Hmmm... I had a bunch more stuff to say, addressing various other aspects of what I said, going into stuff like the nature of reputation, disappointment as a function of exception, and whatnot. But I've rather run out of steam - which is probably for the best. Perhaps at this point I should attempt to make good on my promise to redeem myself by making a more substantive contribution to the debate. (Yes, I know no-one's going to read it, so it doesn't really count as a contribution. Humour me.)
Oh, hang on. I've just discovered the limit on comment length.
I had a conversation with someone I know about what I wrote, and why I wrote it. Their comment was that without giving any explanation as to why I wrote what I did, the whole thing just comes across as arrogant and mean spirited. I think it's worse than that: the cumulative effect of a number of different remarks, that I had thought of as distinct, is one of a sustained, vindictive attack on the whole Martin clan and the horse they rode in on. Now, I could say "that wasn't my intention", but it doesn't matter very much what my intention was: how it comes across is how it comes across, and for that I can only apologize.
More specifically, I have absolutely no reason to doubt that both Martins have lots of genuinely satisfied customers. Also, with regard to the thread I linked to, now that I've done a spot of freelance consulting myself (even introducing the concept of unit testing to a client) I'd say that "consultancy" is a fairly broad concept. I'm still uncomfortable about the "hired gun" aspect of it, but I now know enough about that world to know that I know very little, and so shouldn't be making sweeping statements about it.
I'm aware that what I wrote shows me in a bad light. I could trying to clarify points badly explained, dispel unintended implications, and backtrack on exaggerations and plain mistakes. But I won't. The light is going to get worse in two paragraphs' time.
[Incidentally, you know when someone says "I'm sorry, but..." and you think to yourself "That's not really an apology"? I'm about to do something like that. I'm sorry. But I'll try to redeem myself in some other way later on.]
Mr Martin said that my tone was virulent. Even allowing for my not having explained myself very well (or at all) this is certainly true. I didn't notice at first how much anger there was behind it. It took me by surprise. What's behind the anger? What's always behind anger: pain. For some reason, something hit me in a really, really sore spot. Even though on the internet no-one can hear you scream, they can read the stupid things you write in the heat of the moment. So, yeah, there's a large element of lashing out here: but if I elaborate a little bit, perhaps some relevance to the matter in hand might become apparent.
Here's a key bit of context: the other year I was on a project in which I may have made mistakes that put lives in danger.
When I say "may" I don't doubt that I made mistakes. The nature of the work, the poor usability of the tools being used, meant that even a momentary lapse in concentration could easily result in a slip which would either go undetected or necessitate time-consuming rework. Problems tended to snowball. It would have been difficult work, even if it weren't being done in a noisy office. My uncertainty regards the extent to which the data we were dealing with was safety critical, and how much further scrutiny it would be subject to: I heard different things from different people, and don't know who to believe. (The truth can be a complex thing to unravel, even without people acting to cover their backs or to save face.)
The real mistake I made, however, came long before, and isn't one that can be easily blamed on circumstances. For a long period before I had become fatalist, and for the sake of a quiet life I'd been too cowardly to push back against things that I could see were wrong. It got to the point where it just seemed par for the course that I ended up with a computer that seized up on a daily basis.
Extreme stress is an interesting experience, although one that's probably best enjoyed when you're not doing anything important at the time. (Mind you, the warnings you get on packs of beta blockers are scary, especially for an asthmatic like me.) A complicating factor at this time was a bout of naive optimism: that if everyone were less coy about problems at work then it would be possible to tackle the root causes, that one should be the change one wishes to see, etc. Crazy, I know. Anyway, I fear I'm digressing.
I'm trying to bring this around to my first beef with Mr Martin, which isn't really a beef with Mr Martin so much as the habit of devaluing "home grown" knowledge in favour of that which is "bought in" (books, training courses, certification, even blog posts). The thing is that, as far as I can work out, some lessons have to be learned the hard way: even when a piece of second-hand wisdom is true, it does no good without a visceral understanding as to why it is true. There's not much point in a company being well informed about good practice if it then says, in effect: "none of the software for this project is being delivered to the customer, therefore the normal principles of software engineering don't apply."
The other thing I wanted to say about bought in knowledge is that there is always more to be had, and always someone trying to sell it. (At times it can seem akin to the situation with theories in social psychology, as described by Michael Billig when he said that "psychologists treat theories like toothbrushes: no one would wish to use someone else's.") In my experience, constantly chopping and changing the ways things are done, in pursuit of some best way, can be enormously destructive. Much better to have a reasonably good way, and stick to it, perhaps tweaking it now and again in the light of experience. Apart from anything else, tacit knowledge gets embedded in the way things are done, and can only really be picked up through doing: its "knowing how" rather than "knowing that", skill rather than information.
This sort of brings me on to why I didn't address Mr Martin's essay. The reason was that it seemed rather lightweight: the diagnosis was, as far as I could see, that if people didn't sufficiently value software development expertise then it was because no-one had pointed out to them that software development is a skilled activity and that the skills can't be acquired instantly. Surely, I thought, it is too obvious to be worth saying. Moreover, when someone says something to obvious to be worth saying, surely they must have an ulterior motive. Hence, in my ire, I assumed Mr Martin must be trotting out easy pieces as a form of self-promotion.
The are a number of grounds for saying that this was stupid of me, but one of them is that what Mr Martin said wasn't, in fact, too obvious to be worth saying. Sometimes things are worth saying even when they are obvious: what is obvious to one person isn't obvious to others. Moreover, I should have known this from my own experience. (There is a software company I know where the - now retired - HR manager said that "technical competencies" were relatively unimportant, as anything technical could be picked up on a short training course.)
Hmmm... I had a bunch more stuff to say, addressing various other aspects of what I said, going into stuff like the nature of reputation, disappointment as a function of exception, and whatnot. But I've rather run out of steam - which is probably for the best. Perhaps at this point I should attempt to make good on my promise to redeem myself by making a more substantive contribution to the debate. (Yes, I know no-one's going to read it, so it doesn't really count as a contribution. Humour me.)
Oh, hang on. I've just discovered the limit on comment length.
[deleted]
Mr. Newton. Why is that the question? What does who I am have to do with what I wrote?
Now, if you'd like to know who I am, I'll be glad to tell you. I've been writing code since 1970. I started on PDP/8s and PDP/11s. I have written BAL, COBOL, Fortran, PL/1, C, C++, Java, C#, Ruby, Python, Clojure, and a bunch of other language I can't remember. I spent many years writing embedded software in 8080 assembler, to control telecommunications micr-controllers. I spent a year and a half working at Rational with Grady Booch on the first two releases of Rose (for my sins). I have written five books on software development and have edited two more. I called the meeting that founded the Agile movement, and served as the first chairman of the Agile Alliance. I was the editor-in-chief of the C++ Report for three years. I am the creator of cleancoders.com, which offers software development video training. Nowadays I spend my time speaking, teaching, making videos, writing blogs, and writing Clojure and Java code.
Is there anything else you'd like to know?
(BTW, the term "uber-hacker" is not mine, and is incorrect. I shall endeavor to get that removed.)
Now, if you'd like to know who I am, I'll be glad to tell you. I've been writing code since 1970. I started on PDP/8s and PDP/11s. I have written BAL, COBOL, Fortran, PL/1, C, C++, Java, C#, Ruby, Python, Clojure, and a bunch of other language I can't remember. I spent many years writing embedded software in 8080 assembler, to control telecommunications micr-controllers. I spent a year and a half working at Rational with Grady Booch on the first two releases of Rose (for my sins). I have written five books on software development and have edited two more. I called the meeting that founded the Agile movement, and served as the first chairman of the Agile Alliance. I was the editor-in-chief of the C++ Report for three years. I am the creator of cleancoders.com, which offers software development video training. Nowadays I spend my time speaking, teaching, making videos, writing blogs, and writing Clojure and Java code.
Is there anything else you'd like to know?
(BTW, the term "uber-hacker" is not mine, and is incorrect. I shall endeavor to get that removed.)
My mistake. This was just another one of your misreported facts. The bio line on my blog says that I am an über _geek_; not an über _hacker_. And with _that_ characterization I must agree.
Live long and prosper.
Live long and prosper.
I first encountered him with this book:
Designing object-oriented C++ applications using the Booch method
and really liked: Agile Software Development: Principles, Patterns and Practices.
I didn't think Clean Code was worth it though.
and really liked: Agile Software Development: Principles, Patterns and Practices.
I didn't think Clean Code was worth it though.
https://en.wikipedia.org/wiki/Robert_Cecil_Martin
He’s the head of the agile movement.
He’s the head of the agile movement.
AFAIK, not the head, but one of the founders - one of the signatories of the agile manifesto back in 2000:
http://agilemanifesto.org/
http://agilemanifesto.org/
Ironically your argument fails as it depends entirely on skill level. A highly skilled surgeon could perform emergency surgery without standard resources, and you could run an emergency hospital without receptionists.
Let's not get distracted by shitty analogys.
Let's not get distracted by shitty analogys.
Would a hospital staffed only by highly skilled surgeons constantly performing unassisted emergency surgery economically out-compete a hospital with nurses and receptionists?
I'm more commenting on the effectiveness of arguing through shitty analogy. There's no logical reason to imagine any of this let alone compare it to the programming industry. It breeds disagreement, distraction, and useless side-discussion that treads water and makes people angry at each other.
And if you want to keep taking this to an extreme, using the shitty analogys provided:
Would a hospital with 5 highly trained surgeons and no receptionists or nurses complete more surgery than a hospital with no surgeons and 100 nurses and 600 receptionists? Yes. But now we're saying absolutely nothing about the programming industry or what's we think is wrong with it.
And if you want to keep taking this to an extreme, using the shitty analogys provided:
Would a hospital with 5 highly trained surgeons and no receptionists or nurses complete more surgery than a hospital with no surgeons and 100 nurses and 600 receptionists? Yes. But now we're saying absolutely nothing about the programming industry or what's we think is wrong with it.
> and you could run an emergency hospital without receptionists.
Not for long, at least in the US, without replacing receptionists at least 1:1 with other people doing the job of receptionists (which, in the emergency room of a hospital, is entirely about getting identification, signed consent for treatment, and insurance/payment information from patients so that the hospital gets paid for the service it provides.)
Not for long, at least in the US, without replacing receptionists at least 1:1 with other people doing the job of receptionists (which, in the emergency room of a hospital, is entirely about getting identification, signed consent for treatment, and insurance/payment information from patients so that the hospital gets paid for the service it provides.)
To pull the analogy through to the extremes, even a highly skilled surgeon might not be able to do it because he doesn't know how to improvise, refuses to operate in a non-hospital environment, or insert a billion other reasons in here.
tl;dr, T-shaped skillsets are good, specialists are good.
tl;dr, T-shaped skillsets are good, specialists are good.
> Is our industry doing the equivalent of offering free rides to hopeful software developers, calling them pilots, and throwing them by the thousands into airplanes just to watch them crash and burn? The evidence is pretty compelling. There's a lot of crashing and burning out there. Is that because nobody is signing the log?
No, it's because some companies do a really bad job of interviewing and hiring developers. This could be for a few reasons:
1. Companies are so hungry to attract developers they make an offer to the first candidate that seems remotely competent, only to see him/her struggle when they get out of the bootcamp and into the trenches of day to day work.
2. Companies have clueless people interviewing candidates for technical positions, and just do a bad job evaluating them.
For all of those "novices" that these bootcamps and such produce, some will go on to fizzle out, but my guess is some of them are actually talented/hard working enough to stick with it and evolve into competent developers. At the end of the day, it's still the responsibility of the company doing the hiring to determine which is which.
The need for developers is only going to increase... so yes, we do need those hordes of novices, but with that need comes an increased responsibility to focus your hiring/recruiting efforts.
No, it's because some companies do a really bad job of interviewing and hiring developers. This could be for a few reasons:
1. Companies are so hungry to attract developers they make an offer to the first candidate that seems remotely competent, only to see him/her struggle when they get out of the bootcamp and into the trenches of day to day work.
2. Companies have clueless people interviewing candidates for technical positions, and just do a bad job evaluating them.
For all of those "novices" that these bootcamps and such produce, some will go on to fizzle out, but my guess is some of them are actually talented/hard working enough to stick with it and evolve into competent developers. At the end of the day, it's still the responsibility of the company doing the hiring to determine which is which.
The need for developers is only going to increase... so yes, we do need those hordes of novices, but with that need comes an increased responsibility to focus your hiring/recruiting efforts.
I think people underestimate how hard it is to find good developers. I've spent a lot of time thinking about it, experimenting with hiring processes, and hiring yet I still wouldn't trust my success rate very much.
The issue is that we don't have any objective measures as to what makes good software. This means that everything we do in the hiring space is subjective, which makes it really difficult to do rigorous study/improvement on.
That said, novice programmers even excellent ones are exponentially less valuable than experienced ones. But, the ratio of good developer to bad seems constant across experience levels.
In my mind the 2 biggest issues in finding good developers are: 1) the cost of novice developers. The market has driven demand so high that it is too costly to experiment/mentor young developers knowing that they will (and probably should) only provide 2 years of valuable work (1 year of uselessness and 2 of value in a 3 year hire). 2) the senseless ageism in our industry. The idea that older developers are somehow inflexible or out of touch just doesn't gel with my personal experience. The older developers who are still out developing are doing it because they enjoy it and keep up with new technology. If they didn't they would have left the profession a long time ago.
Unfortunately, this has led me to a policy of hiring a few more experienced developers instead of a more healthy mix of novice/experience. I know that makes me part of the problem but I can't afford to be otherwise.
The issue is that we don't have any objective measures as to what makes good software. This means that everything we do in the hiring space is subjective, which makes it really difficult to do rigorous study/improvement on.
That said, novice programmers even excellent ones are exponentially less valuable than experienced ones. But, the ratio of good developer to bad seems constant across experience levels.
In my mind the 2 biggest issues in finding good developers are: 1) the cost of novice developers. The market has driven demand so high that it is too costly to experiment/mentor young developers knowing that they will (and probably should) only provide 2 years of valuable work (1 year of uselessness and 2 of value in a 3 year hire). 2) the senseless ageism in our industry. The idea that older developers are somehow inflexible or out of touch just doesn't gel with my personal experience. The older developers who are still out developing are doing it because they enjoy it and keep up with new technology. If they didn't they would have left the profession a long time ago.
Unfortunately, this has led me to a policy of hiring a few more experienced developers instead of a more healthy mix of novice/experience. I know that makes me part of the problem but I can't afford to be otherwise.
No it's because the industry and schools do a bad job of training novice programmers.
The overwhelming majority of bespoke software is a CRUD app in disguise (to a lesser or greater extent). You don't need to be an expert to develop things like that - a basic knowledge data structures, connecting to a database, and some UI and off you go. That isn't going to change. So I would argue that yes, we need the horde. We need more of the people at the "bottom" doing the boring stuff than we need at the top doing the hard stuff.
I don't know about "overwhelming majority," but yes, there is a very large slice of software that is essentially CRUD.
In my recent experience, though, it's almost always attached to, part of, or feeding into or off of something else, whether that's a CMS, API's, satellite sites, or some sort of proprietary custom plumbing.
Many things can be done by novices, and the limited supply of experts means they can't do everything. But for many projects, that boring stuff at the bottom handles the data that's vital to everything else, and it's vital to be careful when using novices to work on the lifeblood of your business. Without careful management, you'd better hope they randomly fail to introduce any serious design flaws or security issues given only "basic knowledge data structures, connecting to a database, and some UI."
In my recent experience, though, it's almost always attached to, part of, or feeding into or off of something else, whether that's a CMS, API's, satellite sites, or some sort of proprietary custom plumbing.
Many things can be done by novices, and the limited supply of experts means they can't do everything. But for many projects, that boring stuff at the bottom handles the data that's vital to everything else, and it's vital to be careful when using novices to work on the lifeblood of your business. Without careful management, you'd better hope they randomly fail to introduce any serious design flaws or security issues given only "basic knowledge data structures, connecting to a database, and some UI."
> We need more of the people at the "bottom" doing the boring stuff than we need at the top doing the hard stuff.
I disagree with that premise. In software, it's all virtual. It can be copied easily. So why there should be boring work at all? I mean, in building houses, sure, one has to go out and actually lay the bricks. But in software?
So why we can't write the CRUD app just once (or twice perhaps, so we wouldn't have a monoculture) and be done with it, work on something more interesting?
In my view, if you're in software doing boring work, you're doing something wrong. Doesn't mean you cannot get a nice paycheck for that, though. :-)
I disagree with that premise. In software, it's all virtual. It can be copied easily. So why there should be boring work at all? I mean, in building houses, sure, one has to go out and actually lay the bricks. But in software?
So why we can't write the CRUD app just once (or twice perhaps, so we wouldn't have a monoculture) and be done with it, work on something more interesting?
In my view, if you're in software doing boring work, you're doing something wrong. Doesn't mean you cannot get a nice paycheck for that, though. :-)
Is our industry doing the equivalent of offering free rides to hopeful software developers, calling them pilots, and throwing them by the thousands into airplanes just to watch them crash and burn?
With some exceptions, it's less dangerous when a novice programmer writes ugly code than when a pilot crashes a plane.
So we shouldn't require as much caution around letting people program as we do in letting them fly an airplane.
With some exceptions, it's less dangerous when a novice programmer writes ugly code than when a pilot crashes a plane.
So we shouldn't require as much caution around letting people program as we do in letting them fly an airplane.
http://www.wired.com/software/coolapps/news/2005/11/69355?cu...
1982 -- Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.
1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.
What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.
June 4, 1996 -- Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5's faster engines trigger a bug in an arithmetic routine inside the rocket's flight computer. The error is in the code that converts a 64-bit floating-point number to a 16-bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5 than in the Ariane 4, triggering an overflow condition that results in the flight computer crashing.
First Flight 501's backup computer crashes, followed 0.05 seconds later by a crash of the primary computer. As a result of these crashed computers, the rocket's primary processor overpowers the rocket's engines and causes the rocket to disintegrate 40 seconds after launch.
November 2000 -- National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.
Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.
The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.
At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder.
also http://en.wikipedia.org/wiki/List_of_software_bugs#Military
The software error of a MIM-104 Patriot, caused its system clock to drift by one third of a second over a period of one hundred hours – resulting in failure to locate and intercept an incoming missile. The Iraqi missile impacted in a military compound in Dhahran, Saudi Arabia (February 25, 1991), killing 28 Americans.
A Chinook crash on Mull of Kintyre in June 1994. A Royal Air Force Chinook helicopter crashed into the Mull of Kintyre, killing 29. This was initially dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence to convince a House of Lords inquiry that it may have been caused by a software bug in the aircraft's engine control computer.
In April 1992 the first F-22 Raptor crashed while landing at Edwards Air Force Base, California. The cause of the crash was found to be a flight control software error that failed to prevent a pilot-induced oscillation.
http://www.computerworld.com/s/article/9183580/Epic_failures...
Osprey aircraft crash
Two weeks before Christmas in 2000, a U.S. Marine Corps Osprey, a hybrid airplane and helicopter, suffered a hydraulic system fault that should have been remedied without loss of life. A hydraulic line broke in one of the two engine cases as the Osprey was shifting from airplane to helicopter mode for landing.
According to the Marine Corps major general who presented reports during the investigation of the incident, the trouble was "compounded by a computer software anomaly." The flight-control computer stopped the rotation of the engine pods when it detected the hydraulic failure.
The pilots went through the normal procedure and pressed the primary reset button to re-engage the pods. At this point, both prop rotors went through "significant pitch and thrust changes," which led to a stall. The plane crashed into a marsh and killed all four Marines onboard.
1982 -- Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.
1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.
What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.
June 4, 1996 -- Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5's faster engines trigger a bug in an arithmetic routine inside the rocket's flight computer. The error is in the code that converts a 64-bit floating-point number to a 16-bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5 than in the Ariane 4, triggering an overflow condition that results in the flight computer crashing.
First Flight 501's backup computer crashes, followed 0.05 seconds later by a crash of the primary computer. As a result of these crashed computers, the rocket's primary processor overpowers the rocket's engines and causes the rocket to disintegrate 40 seconds after launch.
November 2000 -- National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.
Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.
The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.
At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder.
also http://en.wikipedia.org/wiki/List_of_software_bugs#Military
The software error of a MIM-104 Patriot, caused its system clock to drift by one third of a second over a period of one hundred hours – resulting in failure to locate and intercept an incoming missile. The Iraqi missile impacted in a military compound in Dhahran, Saudi Arabia (February 25, 1991), killing 28 Americans.
A Chinook crash on Mull of Kintyre in June 1994. A Royal Air Force Chinook helicopter crashed into the Mull of Kintyre, killing 29. This was initially dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence to convince a House of Lords inquiry that it may have been caused by a software bug in the aircraft's engine control computer.
In April 1992 the first F-22 Raptor crashed while landing at Edwards Air Force Base, California. The cause of the crash was found to be a flight control software error that failed to prevent a pilot-induced oscillation.
http://www.computerworld.com/s/article/9183580/Epic_failures...
Osprey aircraft crash
Two weeks before Christmas in 2000, a U.S. Marine Corps Osprey, a hybrid airplane and helicopter, suffered a hydraulic system fault that should have been remedied without loss of life. A hydraulic line broke in one of the two engine cases as the Osprey was shifting from airplane to helicopter mode for landing.
According to the Marine Corps major general who presented reports during the investigation of the incident, the trouble was "compounded by a computer software anomaly." The flight-control computer stopped the rotation of the engine pods when it detected the hydraulic failure.
The pilots went through the normal procedure and pressed the primary reset button to re-engage the pods. At this point, both prop rotors went through "significant pitch and thrust changes," which led to a stall. The plane crashed into a marsh and killed all four Marines onboard.
Yes. Software is important and I like your examples. What training would prevent them, yet still make all the advances possible? People die and it is OK as long as we keep the number low. I am leaving for an orienteering run right now. I may be injuried or die due to it but I'm glad I can take the (low) risk.
yes, Uncle Bob, we do need hordes of novices.
Because in the days of yore only monks and priests knew how to read and write, and that was bad. Getting everyone to read and write is good. 90% of what they write will be crap, but that's better than not having them write at all.
Obviously they're not going to be writing commercial or critical systems. Learning to code helps people deal with technology, but it doesn't make them professional coders. Just like learning to write a shopping list is useful but doesn't make me a journalist.
Opposing people learning things because what they might create with that knowledge is just wrong.
Because in the days of yore only monks and priests knew how to read and write, and that was bad. Getting everyone to read and write is good. 90% of what they write will be crap, but that's better than not having them write at all.
Obviously they're not going to be writing commercial or critical systems. Learning to code helps people deal with technology, but it doesn't make them professional coders. Just like learning to write a shopping list is useful but doesn't make me a journalist.
Opposing people learning things because what they might create with that knowledge is just wrong.
> Opposing people learning things because what they might create with that knowledge is just wrong
He doesn't oppose people learning things.
> Obviously they're not going to be writing commercial or critical systems.
No. That's exactly what he's talking about. The trend to hire more people rather than better people.
FTA: "Do we really need to keep on recruiting and training cannon fodder to throw at software projects? Or should we rethink this."
Take a few minutes to read the article.
He doesn't oppose people learning things.
> Obviously they're not going to be writing commercial or critical systems.
No. That's exactly what he's talking about. The trend to hire more people rather than better people.
FTA: "Do we really need to keep on recruiting and training cannon fodder to throw at software projects? Or should we rethink this."
Take a few minutes to read the article.
I had a big project failed once because at the beginning out rockstar programmer/ninja/free electron (and he was a genuine one) threw a temper tantrum and said - I am bored of working with Microchip Pics (don't worry if you are young and don't know what that is) I want to use something more powerful - so we switched vendors, the stack to keep him satisfied. It went downhill. Sometimes you need mediocre guy for a non demanding job.
A bored talented programmer can sink a project as good as incompetent one.
A bored talented programmer can sink a project as good as incompetent one.
I think what you encountered is a different type of trap, the trap of the talented jerk. The guy/gal who is brilliant, so they're allowed to get away with a crappy and/or irrational attitude. Sometimes this works out well, but other times it'd be better to hire someone may not be of the same caliber skills-wise, but has a better attitude and is more pragmatic.
Your coworker might not have been a true "jerk" per se, but he certainly sounded irrational.
Your coworker might not have been a true "jerk" per se, but he certainly sounded irrational.
I did... the point with people learning to code is precisely not that they're going to get hired to write code (that's what we professionals do).
The current craze for teaching people to code that he references has (in my experience at least) got nothing to do with creating a horde of junior devs, but is to do with people waking up to the fact that they're effectively illiterate.
I agree entirely that 9 women can't produce a baby in one month, and that hiring 20 random junior devs is not going to make a development task go faster than 5 experienced devs in a decently managed development team.
The current craze for teaching people to code that he references has (in my experience at least) got nothing to do with creating a horde of junior devs, but is to do with people waking up to the fact that they're effectively illiterate.
I agree entirely that 9 women can't produce a baby in one month, and that hiring 20 random junior devs is not going to make a development task go faster than 5 experienced devs in a decently managed development team.
> I did... the point with people learning to code is precisely not that they're going to get hired to write code (that's what we professionals do).
So then I don't understand the point of your comment, because it's not a response to anything said in the original article. You are responding to Uncle Bob on an issue he does not bring up.
Unless you are referring to the part about code academies, where he says:
"These programs are attracting people to them, and employers, desperate to add developers, are hiring them."
Which flies in the face of what you say in this comment.
So, I don't understand. What are you responding to? Maybe you misunderstood the premise?
So then I don't understand the point of your comment, because it's not a response to anything said in the original article. You are responding to Uncle Bob on an issue he does not bring up.
Unless you are referring to the part about code academies, where he says:
"These programs are attracting people to them, and employers, desperate to add developers, are hiring them."
Which flies in the face of what you say in this comment.
So, I don't understand. What are you responding to? Maybe you misunderstood the premise?
You're right... re-reading it carefully I found I missed the point he was making about companies hiring unskilled developers.
I guess I read the whole article with the mindset that coding is not primarily a commercial activity. Therefore hordes of novices is a great thing, a fantastic thing and his point got a little hard to reach for me because I'm not seeing them as potential hires for a commercial team and all I saw was scathing criticism of newbies.
I've been a big fan of his work on software craftsmanship, something I get completely; it's the difference between a master carpenter and a DIY carpentry enthusiast. Don't let the DIY enthusiast build your house, but don't discourage them either, the world needs their enthusiasm!
I guess I read the whole article with the mindset that coding is not primarily a commercial activity. Therefore hordes of novices is a great thing, a fantastic thing and his point got a little hard to reach for me because I'm not seeing them as potential hires for a commercial team and all I saw was scathing criticism of newbies.
I've been a big fan of his work on software craftsmanship, something I get completely; it's the difference between a master carpenter and a DIY carpentry enthusiast. Don't let the DIY enthusiast build your house, but don't discourage them either, the world needs their enthusiasm!
He makes a good point that one more competent developer is much more valuable than multiple incompetent devs.
The first part of the piece, about how much software is needed and for how many uses, suggests another point he does not make -- namely that there is a lot of redundancy. In the universe of softare, how many independently developed, duplicative solutions to essentially the same functionality, code pattern or use case are there? Probably quite a lot, right?
The efforts of the limited number of good devs societies have on tap, obviously would go a lot further if there were more re-use and sharing. I know I'm an idealistic outlier in believing software should never have been deemed copyrightable, but the more we go in the "Free" direction - with GPL/BSD type licences and such - the better off we'll all be, in a macro view.
The first part of the piece, about how much software is needed and for how many uses, suggests another point he does not make -- namely that there is a lot of redundancy. In the universe of softare, how many independently developed, duplicative solutions to essentially the same functionality, code pattern or use case are there? Probably quite a lot, right?
The efforts of the limited number of good devs societies have on tap, obviously would go a lot further if there were more re-use and sharing. I know I'm an idealistic outlier in believing software should never have been deemed copyrightable, but the more we go in the "Free" direction - with GPL/BSD type licences and such - the better off we'll all be, in a macro view.
If one doctor can transplant a heart in ten hours, can ten nurses transplant that heart in one hour? Can a hundred nursing assistants transplant that heart in six minutes? Can six hundred hospital receptionists transplant that heart in one minute?
All of the people involved have useful and important skills, but they are not appropriate or relevant for the operation in question. My only change here would have been to swap receptionists out for interns: The skills are still relevant, but the experience is not there and the expectation is still unreasonable.
No, development is not surgery (certainly not brain surgery, and usually not heart surgery). But it is often complex work that requires not just an understanding of what to do, but also how to do it, why to do it that way, what alternatives are available and how they might benefit the work in the future, how requirements tend to change, the difference between what clients/bosses say and what clients/bosses mean...
It's vital that we have new developers. But the point of having new developers is that they become experienced developers; a swarm of n00bs is not, in and of itself, valuable. Treating it as such is dangerous, as many, many rescue projects painfully illustrate.
All of the people involved have useful and important skills, but they are not appropriate or relevant for the operation in question. My only change here would have been to swap receptionists out for interns: The skills are still relevant, but the experience is not there and the expectation is still unreasonable.
No, development is not surgery (certainly not brain surgery, and usually not heart surgery). But it is often complex work that requires not just an understanding of what to do, but also how to do it, why to do it that way, what alternatives are available and how they might benefit the work in the future, how requirements tend to change, the difference between what clients/bosses say and what clients/bosses mean...
It's vital that we have new developers. But the point of having new developers is that they become experienced developers; a swarm of n00bs is not, in and of itself, valuable. Treating it as such is dangerous, as many, many rescue projects painfully illustrate.
"Get off my lawn you damn kids!"
Today's novice is tomorrow's expert.
No matter how much of an expert you think you are, you are a novice to someone else.
If we go back and look at your code from X years ago (or even last week), are you going to be comfortable or are you going to squirm a little and want to make excuses for certain things?
Bad code making it into production and causing problems for users is not the fault of the novice developer, it's the fault of their team lead/manager. Who shouldn't be a novice. If they are then that's an organizational problem, and not one caused by the mere existence of novices.
Today's novice is tomorrow's expert.
No matter how much of an expert you think you are, you are a novice to someone else.
If we go back and look at your code from X years ago (or even last week), are you going to be comfortable or are you going to squirm a little and want to make excuses for certain things?
Bad code making it into production and causing problems for users is not the fault of the novice developer, it's the fault of their team lead/manager. Who shouldn't be a novice. If they are then that's an organizational problem, and not one caused by the mere existence of novices.
The problem with mentoring programmers is: who is a good mentor? Looking back at when I started coding, very few of the senior people there would not have been good mentors. They simply weren't good enough. They would have taught me the wrong things.
Also, of course we need more good developers. The problem is that there aren't enough good people to be found (this is not a problem of too few places where you learn to code). Plus, the demand for more software seems pretty limitless.
Also, of course we need more good developers. The problem is that there aren't enough good people to be found (this is not a problem of too few places where you learn to code). Plus, the demand for more software seems pretty limitless.
Yes. There's also difficulty in finding mentors. There are sites that pop up claiming to offer software mentorship, but most seem to be just people who are willing to help you with an issue you're having with your code. That is not a good mentor-protege relationship.
There's also a problem finding decent students/coworkers that listen. I don't know how many times I've made suggestions and recommendations, just to be ignored.
I co-lead a local programming user group and we commonly help people. Frequently we encounter people that want us to fix the bug in one line of code and don't want help in fixing the structure, the function, the readability or overall program.
I co-lead a local programming user group and we commonly help people. Frequently we encounter people that want us to fix the bug in one line of code and don't want help in fixing the structure, the function, the readability or overall program.
Exactly. Not enough developers care enough to be either good mentors or good mentees.
While I enjoyed and partly agreed with Uncle Bob's equivalent of "Get off my lawn", it would be excellent if he also proposed something that resembled a solution to the problem. I struggled at my first dev job because school only taught me the basics, not modern full-stack agile software engineering. I worked with a team that had everything from testing to deployment polished and near perfect. However, some of them gave me a chance, and today, I suck a lot less at writing good, clean, tested code. Our industry will need to continue to do things like that if we hope to improve over time. Otherwise, history will just repeat itself.
One of the problems with software engineering training is that few schools take the "engineering" part seriously. Instead they train programmers or software developers. If engineering was taken more seriously then they would teach SWEBOK and SEMAT along with coding. Of course, many schools would argue that software engineering is a young profession and that SWEBOK and SEMAT are not yet fully formed. But nevertheless we do have people that are trying to apply some engineering rigor to the process of developing software and there is something there for all of us to learn, even if these things take another decade or two to become fully formed.
Have you ever worked at a job where a guy who learned to program 20 years ago has to sign off on everything you do? I did, and it was awful. I've also worked at a place that hired nothing but fresh graduates, and that... actually turned out pretty well. There were cases where they wrote more code when they needed to, or used an unsafe construct when there was a better alternative... but they were willing to reason about things, to experiment, rather than just "this is how we do it". I'll take an untrained grad over someone who rigidly follows procedures any day.
This discussion reminds me of Joel Spolsky's "Hitting the High Notes":
http://www.joelonsoftware.com/articles/HighNotes.html
Instead of debating with every other PHB, PM/BA, or clueless customer, I have them read this first. It's fundamental for understanding how to use high achievers to get things done.
(Love this part: "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.")
http://www.joelonsoftware.com/articles/HighNotes.html
Instead of debating with every other PHB, PM/BA, or clueless customer, I have them read this first. It's fundamental for understanding how to use high achievers to get things done.
(Love this part: "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.")
As a relative "novice" compared to the author, I welcome the suggestion that more formalized mentorship and "sign-off" by someone with experience would improve programming. Sorry I can't do your apprenticeship program. I see what you did there. Up scope! http://www.8thlight.com/apprenticeship
The problem is that this cannot be implemented at scale, and certainly will not respond to demand. One may not have the opportunity to find in person mentors, but instead have the internet and a problem to solve. You have to navigate through on your own to find the people that do it right, and you may latch on to the wrong people!
On the hiring side - for critical systems with a profit incentive and high potential, (or for a company with a unique mission that entices developers) you can afford to find and hire the bard. For other tasks, something is better than nothing so you get mediocre code. (there is still a HUGE market out there for that small something for small to medium businesses).
For outlying scenarios where markets have become imbalanced by regulation or law (such as government contracting) you get incentives to put butts in seats regardless of experience as long as they meet the criteria. (Java cert = signed pilot's card right?)
Certification is hard to get right, as is mastery. I applaud you for creating an environment to provide guidance and make mistakes and would welcome a larger scale effort to do so.
The problem is that this cannot be implemented at scale, and certainly will not respond to demand. One may not have the opportunity to find in person mentors, but instead have the internet and a problem to solve. You have to navigate through on your own to find the people that do it right, and you may latch on to the wrong people!
On the hiring side - for critical systems with a profit incentive and high potential, (or for a company with a unique mission that entices developers) you can afford to find and hire the bard. For other tasks, something is better than nothing so you get mediocre code. (there is still a HUGE market out there for that small something for small to medium businesses).
For outlying scenarios where markets have become imbalanced by regulation or law (such as government contracting) you get incentives to put butts in seats regardless of experience as long as they meet the criteria. (Java cert = signed pilot's card right?)
Certification is hard to get right, as is mastery. I applaud you for creating an environment to provide guidance and make mistakes and would welcome a larger scale effort to do so.
Hoard == a secret stash
Horde == a large group
As the guy who formulated SOLID principles, co-created the Agile manifesto, and formulated the red-green-refactor process of doing TDD, I'd say that we should listen to what he has to say.
Why do we keep training programmers in university to bang out low-level unstructured code? We know better and some schools like MIT with SICP have been following a different approach, but why is this not more widespread?
Java is a horrible language to teach to new developers because it has traps all over the place that are best avoided. If a course started with DDD for a month before the first line of code is written, then perhaps Java would be OK.
I'd still like to see all developers learn some machine coding and assembler but that should be something that you leave to 2nd or 3rd year after you have a grounding in how to structure programs.
Why do we keep training programmers in university to bang out low-level unstructured code? We know better and some schools like MIT with SICP have been following a different approach, but why is this not more widespread?
Java is a horrible language to teach to new developers because it has traps all over the place that are best avoided. If a course started with DDD for a month before the first line of code is written, then perhaps Java would be OK.
I'd still like to see all developers learn some machine coding and assembler but that should be something that you leave to 2nd or 3rd year after you have a grounding in how to structure programs.
I think he is basically arguing for a professional organization of programmers, which would give out certifications and (wink, wink) make sure their salaries won't get too low by limiting competition. (I don't necessarily disagree, just saying.)
Press the G key while you're on the website and you'll see their layout grid.
EDIT: it's this: https://github.com/dotjay/hashgrid
EDIT: it's this: https://github.com/dotjay/hashgrid
Don't hire and mentor a newbie or a graduate of a coding school, just hire a master coder+pilot. Perhaps the consultancy team at 8th Light could pick up your project for thousands of dollars a day...
There is a definite argument to made for putting in-place more rigorous standards for developer education. My wife is a nurse, and there are very strict standards for getting a nursing license and graduating with a BSN degree. After all, she deals with human lives, and mistakes could be deadly. I believe such systems help ensure consistent behavior, and I agree that such a thing might be useful in certain areas of the developer world.
However, we have to be careful, because a big part of software development involves inspiration and creative work. If people aren't interested and encouraged to pursue development as a hobby or career path, where will the masters of the future come from? Think of the amateur, but not so great, photographer hobbyist who grows up to become a legend in their field.
I also have to disagree with Uncle Bob on the use of the term "hordes" to describe "many people interested in a craft". The negative connotation is indicative of the kind of snobbery that people as the top of their field may be entitled to, but certainly doesn't win people over when trying to make a convincing argument. It smacks of somebody looking down from the Ivory Tower of Enlightenment and sneering at the ignorance of the perceived mobs below...
However, we have to be careful, because a big part of software development involves inspiration and creative work. If people aren't interested and encouraged to pursue development as a hobby or career path, where will the masters of the future come from? Think of the amateur, but not so great, photographer hobbyist who grows up to become a legend in their field.
I also have to disagree with Uncle Bob on the use of the term "hordes" to describe "many people interested in a craft". The negative connotation is indicative of the kind of snobbery that people as the top of their field may be entitled to, but certainly doesn't win people over when trying to make a convincing argument. It smacks of somebody looking down from the Ivory Tower of Enlightenment and sneering at the ignorance of the perceived mobs below...
I wonder about the thought process that spawns articles like these.
I'm a novice but I think I do pretty well for myself. I also didn't write my first line of code when I was very young. I didn't get any thrills or anything from programming until I started in my 30s.
Obviously you need hordes of novices. What a preposterous, pretentious thing to say. It's the ultimate "first world problem" of career fields. "We have too many people who want to do this job because the pay is so good, career outlook is so bright, and job satisfaction is so high!"
Yes you'll probably have to work much harder on a good noise filter when hiring, and you will probably have to be ok with taking a chance on hiring "newbs", hoping to get a great one who trains up well.
This is a really geeky rant, and I don't mean that in a good way. I mean it as in totally socially tone deaf. It's like Comic Book Guy from the Simpsons wrote this. I know the author is a well-known guy in the software world but that doesn't change my opinion at all.
I'm a novice but I think I do pretty well for myself. I also didn't write my first line of code when I was very young. I didn't get any thrills or anything from programming until I started in my 30s.
Obviously you need hordes of novices. What a preposterous, pretentious thing to say. It's the ultimate "first world problem" of career fields. "We have too many people who want to do this job because the pay is so good, career outlook is so bright, and job satisfaction is so high!"
Yes you'll probably have to work much harder on a good noise filter when hiring, and you will probably have to be ok with taking a chance on hiring "newbs", hoping to get a great one who trains up well.
This is a really geeky rant, and I don't mean that in a good way. I mean it as in totally socially tone deaf. It's like Comic Book Guy from the Simpsons wrote this. I know the author is a well-known guy in the software world but that doesn't change my opinion at all.
It is probably worth noting that Uncle Bob doesn't seem to be implying that the pilot training model is exactly the model that we should use. His point if you read a bunch of his stuff is that as a profession, we should look beyond our own borders to learn lessons from doctors, accountants, lawyers, pilots, engineers, architects, etc. to advance the level of professionalism in our profession. If software is going to make the world a better place ideas like "move fast and break things" probably isn't going to end up being a net benefit overall, especially for important, life or security critical software.
If we pile in a bunch of novices without proper training and hand them projects that involve account security, personal information, etc. we are going to keep hearing about major security breaches, password hacks, etc.
The more that the software industry has major catastrophic failures costing millions/billions of dollars, the more likely that we get regulated.
If we pile in a bunch of novices without proper training and hand them projects that involve account security, personal information, etc. we are going to keep hearing about major security breaches, password hacks, etc.
The more that the software industry has major catastrophic failures costing millions/billions of dollars, the more likely that we get regulated.
And yet, go our own way too. Software is (or used to be built) like other engineering professions; big design up front, then build (and often have the actual construction done by relatively low-wage workers). Software's much more complicated though.
A question not asked by the piece: is what we do really "heart transplants" and Shakespearean plays? Sure, that surgeon can do the transplant like nobody else and ol' Bill can write a play like nobody else, but what if all the client actually needed was a bandaid or a quip for a greeting card?
I believe there will be as many commercially created sites in the not so distant future as there will be houses.
programmers are the house builders of tomorrow, and they are needy, creating more jobs than the average bricklayer, so they drag a few non-educated along for the ride with them.
All in all a boon for all involved.
programmers are the house builders of tomorrow, and they are needy, creating more jobs than the average bricklayer, so they drag a few non-educated along for the ride with them.
All in all a boon for all involved.
I tend to view people who know the extreme basics of programming as tinkerers or "power users", not as miniature Fabrice Bellards.
I'd rather have a bunch of curious people who want to try their hand at some light automation than people who freak out when anything minor changes.
I'd rather have a bunch of curious people who want to try their hand at some light automation than people who freak out when anything minor changes.
It should be clear that what we need is more software developers, but people who are able to quickly rise above the level of novice.
Generally this is what the interview process is meant to weed out.
Generally this is what the interview process is meant to weed out.
You're completely right, it would be much better if they all went into finance or management. There's no place for people trying to learn real skills.
Does anybody here think that healthcare.gov was put together by experts? Or was it more likely a horde of novices?
I love the idea of starting people on the path to learning how to build applications. However I think he brings up a good point, I can't find on the code academy website where it says "this is a start to long process of learning". appacademy goes as far as to say 12 weeks and you're in.
[deleted]
Should we have associations, guilds, licensing?
I would vote for associations and guilds. I'm not a fan of licensing. I don't think we know enough to license people.
This article is ridiculous. Someone needs to program the software obviously.
So it might take 20 novices coming out of these feeders to find 10 who become decent junior programmers, to get 5 who stick it out to become decent intermediate programmers, to get 1 who becomes a rock star.
But is this so bad? What's the downside? Everyone who falls off along the way becomes someone with tools to make themselves more productive in whatever they do in life.
And what's the alternative?