Woo hooo go Oren!!!!!!!!!!!

I couldn't agree more! :)

You know I sat on a blog post similar to this because...well quite frankly the message won't get out to those who NEED to hear it (the 98% who don't read blogs, who don't go to user group meetings, who don't care about career development). I wrote a message about some embedded software for a cyclotron controller that didn't handle memory correctly on the Alt.NET list.

The full story is that the software would crash because it couldn't allocate memory IN THE MIDDLE OF A TREATMENT SESSION. Fortunately there was a safeguard in the device that turned off the radiation when this happened.

All because some genius never bothered to learn proper memory management.

So yes I agree, just like we have stringent requirements on who can be a doctor, we should have more stringent requirements on who can be a software engineer.

One thing that I have been finding increasingly frustrating when I read posts like Roy's (and the storm of posts that have cropped up since) is that people like attitudes like Roy's (assuming he hasn't been trolling everyone the entire time) seem to be under the impression that the professionals in this industry shouldn't be expected to have to learn anything _that takes time and progressively-gained experience to learn_.

There seems to be this desire, nay insistence (if recent posts around the blogosphere are any indication), that if we can't take TDD down from the weeks to months it takes to really wrap your head around it and truly shift into full-on TDD mode and reduce it to not just "21 Days" or "21 Hours" but even to 21 minutes that there is something wrong with TDD that needs to get fixed. There's nothing wrong with it. Some. Things. Take. Time.

The whole thing smacks of a certain kind of consultant (and, to be clear, I am one... Just not one of the ones I'm about to refer to) that wants to parachute into short-term engagements and foist upon their client's environments tools and/or techniques that they simply can't hope to properly train the permanent staff on before they roll off the contract. Here's a hint to such consultants: If you aren't going to be there long enough to implement something properly, simply don't try to implement it. You can't always just expect that thing to be properly implementable in the time that you happen to be on the contract, regardless of how much you might like to think you can force that to be the case.

As for consultants on longer engagements and perm staff who might be frustrated that you can't get the locals to grok your preferred tools, processes, etc. and/or that mgmt. aren't willing to take the time to train people up and help them learn over time: you simply picked the wrong gig. If you can't change your job, change your job.

I absolutely agree. I always get tired of having to write crappy code just to try to make it simpler for someone to use who doesn't understand what that code does. It's plagued every job I've ever had and I don't see any way to get rid of it outside of having some sort of engineering licensing exam for software engineers (like that have for other kinds of engineers) and improving our education system so that people who go through college or technical programs learn how to actually write good code.

Did you mean "Coddling"?

Cuddling: verb: to hold close in an affectionate manner; hug tenderly; fondle.

Coddling: To treat indulgently; baby. See Synonyms at pamper

:)

Agree wholeheartedly.

It's a shame that the profession of software development is so willing to admit practitioners with such little talent or experience.

Other, older, professions such as Law and Medicine have far more rigorous hurdles to entrance, and thankfully so! Would you want a heart bypass from a surgeon whose only qualification was having thumbed through Wrox's "Beginning Coronary Surgery"?!

It has surprised me more than once how often collage developers where not interested in learning new stuff or improving them self's at what they do. I enjoy discovering new stuff, improving myself. I also enjoy helping others learn new stuff, but only if those are interested in learning it. Else I don't bother.

In almost every profession you have multiple levels of professionalism so why not in our business. I think that will set us apart from the other 98%, good for us.

It takes effort to improve, and not everyone is willing to put effort in to it. plenty of people aren't willing to put effort into life in general.

Well said... :)

I was having an I.M. conversation with my friend about this topic just last night. We were pasting quotes back-and-forth at each other from Roy O's recent wave-making blog post. One of the pastes included the phrase "casual developer."

This one really got me angry. Last time I checked, this is an ENGINEERING DISCIPLINE. I certainly wouldn't do business with "casual chemists" or "casual bridge-builders" (though I fear that latter one might be a little too real). Why is it OK for businesses to hire and pamper "casual developers" to build and maintain their business-critical software?

I don't have an easy answer to that question, other than, in my opinion, it's not OK. On any team in which I have any say in the hiring process, one of the principal maxims must be "casual developers need not apply." I am a Professional, and I only want to work with Professionals.

As long as management will continue to believe that you can change a developper with any other one we have a problem.

True, nobody should ever apologize for working at a professional level, but I think you sometimes suffer from a mildly warped sense of reality derived from your own intelligence and borderline inhuman drive and passion.

You don't need to cater to mediocrity, but you can't avoid factoring mediocrity into your world view, unless of course you go work for some research institute where everyone is as smart and driven as you are.

Of course it is absurd to apologize for any development practice, or to dumb down an otherwise effective practice for the benefit of the lowest common denominator, I agree, but think it goes without saying.

Even so all efforts should be made to make such practices as accessible as possible to the mediocre developer. And by mediocre developer I don't mean your talentless, unmotivated programmer that won't learn anything new, they should put down their keyboards and go home, and not by their own volition, their keyboards should be smacked out of their hands. But in between that minority and the hard core geek squad is a vast ocean of programmers who on one hand do want to do their best and contribute high quality work but on the other won't spend all of their spare free time getting there, which really shouldn't be required to play ball in this club.

I strongly believe that if practices such as TDD were simply introduced to and made part of the default culture of .NET development shops the "masses" would pick them up just fine. Give people time on the clock for training, provide coaches and support, and there you go. If the practices themselves need to be made more accessible for that to become possible, then so be it - things can be made accessible without dumbing them down, but to take the attitude of "keep up or go home" just isn't practical, because if the "masses" meaning the mediocrity meaning the bulk of development staff in the world can't or won't participate in some particular practice, no matter how wonderful it might be, because they are unwilling or incapable, then the practice itself is limited in its usefulness, relegated to the fringes (which probably includes just about everyone who reads your blog).

I see your point... somewhat. But I still disagree. After all, by your reasoning, we should all still be programming in assembly language and be LOVING it.

A huge reason that programming languages have evolved is to make development "easier" by introducing new abstractions that prevent us from being required to think about lower-level constructs (like memory management, CPU register management, pointers, etc.).

Saying that people writing code ("developers") should require extensive knowledge of a computer, and be very smart, etc. is just being elitist. What about kids writing games? Or music software? Or the software of tomorrow? We should require them to go through intesive training? If they have a hard time of it, we should expect them to just quit and go home?

Now, for a "software engineer", i agree. Those people writing software that powers missile defense systems, space shuttles, etc. (the stuff that puts lifes on the line) should require extra work/effort/certifications/etc. But the beauty of software (and the WHOLE reason it is as popular as it is today), is that anybody can try it or do it. It's like we've forgotten the whole empowering aspect of the personal computing revolution.

As a followup, could you imagine 11-12 year olds writing full-fledged paint programs, animation software, music notation software, etc. in C# or Java or C++? If not, why were they able to using Smalltalk back in the Xerox PARC days?

I truly empathize with the sentiment, and If 90% of the software the world needs could be written by 10% of the developers out there it wouldn't be an issue. However, the reality is the profession exhibits the same skills hierachy as any other. And so, if the idea is to just blow off 85% of devs as incapable, then I'd say the imperative is there for MS, Google, Oracle, Amazon, Salesforce, et al to step up efforts to get comprehensive 'platforms', visual modeling, DSLs, and guidance in place for everyone else to use. You know, some form of cloud-based, enterprise Hypercard to tide clients over until they can be attended to by an adept. As much as it might feel good to do so, if we're going to dismiss most devs out of hand, it seems to me we're then either advocating a continuation of bad / unsuccessful software efforts or a very large planetary product backlog. Me? I'd say even if you only lure one dev per talk from the darkside you're doing us all a great service...

@Jason

I find assembler much easier to code in than C# ... it certainly requires less knowledge and less time investment - because it has so few constructs and variations.

C# is an incredibly complex language, more so than C++, it just doesn't have a lot of the pitfalls of C++ ... I would venture to say new languages coming out are getting more complex, not simpler ... and the vast variety of them makes it even harder to keep up.

@Casey

Really? You find assembler easier? Question: how long would it take to write a line-of-business application in assembler that retrieves data from a database (let's say customers) and displays their data in a form that can then be manipulated by end-users?

I would say the problem is not that C# is so complex of a language (well, the introduction of LINQ query comprehensions, lambda expressions, etc. perhaps has me in agreement :P), it's more of a case of how huge the .NET Framework has become. There is almost no way for a single person to know the entire .NET Framework inside and out anymore, which I find disappointing.

But should software development be an engineering discipline?

There are clearly plenty of employers who see us more like white-collar trademen; ie, like carpenters or painters (no disrespect to those professions intended). Its possible to do an excellent job in those sorts of trades, and its also possible to just know the bare minimum.

Plenty of people accept moderate quality painting or carpentry, just as in software. Are we really so different?

One should never "baby" anyone. It does neither party any favors.

That being said, there's also no reason to blow off the concern of cost of maintinance (By to much complexity). If you develop some crazy CORBA system that 10 people in the world can understand, then that's just as bad of engineering as a shmuck that thinks OOP is creating one object and stubbing all his methods off it.

I think everyone here can agree though that the "casual" developer should not ever come into our engineering discussions or decisions of system design.

@Jason

I said it was easier, I didn't say it was faster ...

Touching on your previous comment:

As a followup, could you imagine 11-12 year olds writing full-fledged paint programs, animation software, music notation software, etc. in C# or Java or C++? If not, why were they able to using Smalltalk back in the Xerox PARC days? <<<<br />

At 13 I was writing commercial computer games in Z80 assembly, 6502 assembly, Commodore Basic, Spectrum Basic, and Forth ... if at that age I could teach myself half a dozen languages, I strongly suspect they were simpler. (and sadly I can still count in binary from the experience)

@Oren

Did I mention these programs were written in 1973-1974 and were full-blown GUI applications? Yes, GUI applications in 1973. Yes, there are always exceptions to the rule, but if what it wasn't the exception? A lot of the things we take for granted as developers today came from Smalltalk (or before), and one of the main founding principles of that language was to make programming easier to help usher in the personal computing revolution.

Design Patterns? From the Smalltalk community.

Unit Testing? From the Smalltalk community.

Object-Oriented Programming? From Smalltalk.

Etc.

And if we weren't asking ourselves how to make it easier in the first place, we would have been content in Algol and just never made all the advancements that wouldn't be mainstream until 20-30 years after their time?

I just fear that we're so content in the institution (and so proud of ourselves) that we're not willing to take the time to challenge the underlying assumptions that our systems are built on. Or are we in a Cargo Cult where we learned the techniques without understanding the underlying principles?

If we're not willing to challenge ourselves and our assumptions, we're going to be perfectly content living on what we think is a flat world, with the universe revolving around us.

and what about if you develop a product built on tdd,orm, IOC etc. and then you hit a period of boom where you need to bring people on board fast but fast cannot be done because the learning curve is steep for anyone coming on board.

I am obviously speaking from experience

Aww man, you changed the title from Cuddling! Don't listen to Phil, it was better the first time, you don't want to cuddle with these third rate programmers either!

@Casey

Gotcha :). Although I don't consider writing database-access code in assembly "easier", but that could just be me :P.

And I agree, I think older languages were perhaps easier. I know a lot of developers who got their start with some variant of BASIC. What is today's BASIC? How does an eight year old get hooked on programming today?

I think some older languages were quite elegant too, where the language constructs themselves were built out of the language itself. Recursive language design, yummy.

@Oren

Well, if that's your point, I agree with you completely :). I would never want to cater to the lowest common denominator. I would much rather educate them (even though it may be difficult).

I was simply saying that if our common development practices are only truly understood by the cream-of-the-crop, yet these are the same things that make us better as developers, perhaps it is a sign that there are underlying problems with the system we are building on.

And rather than be proud of how smart we are and that other's should be smarter, we should ask ourselves whether what we are doing is healthy.

a week to get developers up to speed with all these concepts they are unfortunately unfamiliar with?

I would love to be able to grasp nhibernate, tdd, mocking in a week. I'm worried my technology stack is a bit to "out there" coMpared the norm.

Obviously I love it but then I would

I must have misunderstood. I read it as "how can we teach concepts to developers?" not "how can we dumb down the trade so that people can figure it out?"

In reality it's a difficult problem and one that highlights the current state of software development. I liken that 'State-of-the-Art' to us having emerged from the Dark Ages into a Renaissance where a relatively small number of great minds feverishly trade ideas amongst themselves, each putting out a great product. But that is still a long way from an 'Industrial Age' where knowledge then becomes something easily systemitized, packaged, and delivered in forms useful for ordinary folks to accomplish heretofore remarkable tasks.

Learning to code is a process that spans much time. If we ignore those that are on a different curve then we aren't helping much.

'Coddling' is one thing - helping to teach and educate is another.

We need a variety, we have masters, craftsman, apprentices ,all at different levels. If the masters just, ie. write books for other masters, then sure, that is fine. But typically you have masters that 'spread the wealth'.

I think we need to make things 'accessible'. Accessibility means that it's there for me to see it, learn it, take it in. Those 3 words mean I'm interested and seeking to advance myself.

So, I want to learn 'boo' for instance. With some instructions, some tutorials, etc... it is accessible for me to take it and learn it.

Heh. You guys all sound like Linux nuts from /.

"A Printer should be hard to install! Damnit, that's why I get paid!"

:-)

If development becomes so hard that it is near impossible for people to enter into the development market, the work is going to go some place else. Think about it.

One out of two people have less than average intelligence. One out of two drivers have less than average driving skills. One out of two developers have below average skills. Let’s lock up the dumbies, get those bad drivers off the road and tape socks over the hands of those useless developers so they can’t code.

It’s a slippery slope. Good developers are probably pretty smart, and probably get pretty frustrated with not so great developers. Perhaps that is the price you have to pay for being smart, it’s a good problem to have I would guess.

We have a pretty young profession. Gravity has worked the same way for a long time now, so engineering has had a long time to sort it self out. Law, chemistry, etc, they’ve all had a long time to get the training right. I think it is worth our time getting these issues sorted without being too dismissive. Where I live, we are also short on developers, so I try to take a slightly more embracing attitude to developers who may be struggling with some concepts, and I ‘m happy for them to use tools that allows them to get the job down quicker. We need them: not to develop applications for radiology equipment, but I think they can have a crack at the room booking system for their local council.

How do you raise the top of the pyramid? By building up the base. This is true of most professions where the barriers to entry are basically non-existent.

Well said!

@Miles "One out of two people have less than average intelligence. One out of two drivers have less than average driving skills. One out of two developers have below average skills."

I hate to nitpick, but don't you mean median, not average. ;-)

@Ayende I agree with Steve. You can be as in depth as you like, but if there are barriers to grokking it, there is a certain duty to tell people how to get over those barriers. Not do it for them, just highlight the path.

It seems to me that a number of the commenters on this post have the mistaken impression that Oren (or anyone agreeing with Oren) are of the opinion that we should just leave less interested/experienced/talented/whatever developers by the wayside. Quite the opposite! However, the thing that we are (or at least I am) taking issue with is this asinine assumption that everything can be made easy and that we can somehow "build up the base", to paraphrase James, without a) time and b) effort on the part of those who are most in need of learning, supported by c) the commitment of employers to do their part in building up the base.

Of course we should make things as easy for them as possible, no doubt about that. However, one cannot expect easy to always equate to dead simple and instantly (or even quickly) learned. I just take issue with the instant gratification assumption.

Interesting post, and comments... Although in this day and age a lot is expected from the average Joe Developer, the message here sounds a bit too elitist imho. Most of us here (readers of Oren's blog) are totally OK with design patterns, and introduce new tools when we find they add value by habit. Things like that. And I do know more than enough devs who are not interested in improving themselves at all. Still, we should strive to reach to 95% others, instead of thinking ourselves better devs than them. And realize that not every programming job requires the same skillset. If you're a maintenance dev hacking away in VBScript the whole day (I know them personally), you just don't need fancy schmancy "heavy stuff" to get your job done...

This is a problem that will consider to persist as long as businesses can get "functional" code that works good enough to solve their problems.

It is very difficult to convince a businessperson that Potential value justifies extra up front costs. Even more difficult is convincing them that future savings in maintenance (which may or may not happen in their eyes) is worth the extra money it takes to hire a developer that can inject that maintainability into their application...or the extra time it takes to do that instead of "Just getting it done".

A faulty bridge is a very tangible concept, if I drive over a poorly constructed bridge it could collapse and I'll fall 200 feet into the river below. Code that needs to be rewritten will not necessarily cause the company to collapse. When deciding where to place their budget dollars, a company will choose 9 times out of 10 to pocket the savings and incur the technical debt later over paying the costs now and realizing the savings later.

This is the same thing that causes people to swipe their credit card for an item they can't afford and pay three to four times the cost in interest later.

I feel I'm more than acknowledging the paradox inherent in applying resources to herding complexity.

The unfortunate reality, though, is that dealing with certain levels of complexity simply demands high-level skill sets. This is easily seen in other disciplines, such as theoretical physics, where there is a definite competency threshold for doing even basic work in, say, String Theory. Having our top theorists teaching intro Cosmology courses is probably not the best use of scare resources - but still, everyone should be tasked with some form of 'bringing others along'.

And what about common notions of 'hiding' complexity where one attempts to 'leverage' senior devs by having them produce 'infrastructures', 'frameworks', 'components', and 'services' for junior developers to work with and consume? A common sense idea, and basically that's what we're doing relative to the ALT.NET suite - but does that really play well out on your typical applicaiton project? And does it play out well with Agile / XP.

Personally, I'd say that the use of sophisticated tool suites and development methodologies does set a relatively high bar over the sandbox. Think of it this way: driving a car takes skills, but is not that big a deal; flying planes take way more skills and is a big deal. You don't hand the keys to a plane to just anyone. Pilots, by definition, have invested in, or been invested with, a minimum skill set reflecting a minimum threshold of requisite capabilities.

Many people could fly planes, but in the end, only pilots should fly planes, period. That said, however, we still need ground crews, mechanics, flight attendents, controllers, etc. in order to make commercial aviation work. And while software development is less formalized, I don't really think it is all that different, especially relative to the need to invest time and dollars - at every level - in those who show interest and promise in a particulare role.

I totally agree with what you said! These are days I'm spending so much time to let understand my customers, colleagues and more, the same thing you said, I appreciate that you think so about that, and I'm really happy of hear from you. I know you don't like more peoples who writes in your blog, but apart from your personality, I think you're a great one.

But, starting from this consideration you made, I wish share one experience about, a person, "skilled" one told me some days ago, while I'm starting a new project: "here we must have a coding standard.. bla bla bla, we use, we must use as more as possible everything static, static methods, because static methods are faster than instance one...", after I said: "where hell am I"??

This is just a little fact, but I agree with the sentence you said, "I don't think that we need to apologize if we are working at a high level that makes it hard to beginners", you know, what can we expect here where all that you can hear about you day-by-day work is "do it fast, do it dirty but fast" and I add at the end "so it's possible to earn as much as possible with less"...

I want to excuse to everyone who'll read this comment about my poor english..

Bye

The problem is that the "Apes from the Zoo" are already already out and creating projects under the "Crack the Whip" managers.

There is a positive way I tend to think about at it and a negative way I tend to think about it.

I think "A steep learning curve is great for me because I am less intimidated than most by a steep learning curve. More $$$ for me!"

AND I think, "Hmm, I'm worried because there is such a steep learning curve. That means a continuing foothold of Ape-Driven Development out there"

An as such:

• I might have cleanup behind crappy Ape-code at a future company.

• I might have to work for a company who doesn't value quality because the Apes turned out something that sorta works.

• I might have to worry about jobs being outsourced to another country because most managers would rather pay 1/3 the price to get something that sorta works.

• I might have to worry that stable architecture practices are slowly becoming extinct in the Business Software world.

Who knows, in a few generations, if the massive existing Technical Debt isn't paid off rapidly enough, maybe we'll have a Technical Recession?

Just an off-the-top-of-my-head thought.

Ayende,

I find this kind of approach bit difficult to understand and also entirely unhelpful. The "disscusions that have been taking place" have nothing to do with getting good, experienced developers to apologise for their skills and everything to do with acknowledging that there are one hell of alot of developers that find barriers to entry to the top levels of coding.

Simply blaming people for their ignorance and lack of self motivation doesn't actually help improve the industry. It is just a back slapping execise for "good" developers to say how great they are and how rubbish others not like them are. Roy's post and others like it are trying to address the fundamental question of why so many developers coast through their careers, often without even ever being exposed to good practices be they testing, good design or anything else. The low standards of development that are indeed rife in the industry should be questioned not mocked (no pun intended).

On the one hand you seem to say it takes 10 years to be truly good (I agree) but on the hand seem to belittle anyone who hasn't got there yet. How does that help people with two years experience acheive? It doesn't. What it does it place an elitist veneer over quality coding that ultimately perpetuates the difficulties that people have in learning their trade. Sure the self motivated and the people lucky enough to work under good people early in there career will always rise to the top.

I actually this is a critical debate that should really be moving into the academic world. I have long asked myself why so many people with computer science degrees are barely prepared for developing software when they arrive on the job market. There is definately a huge learning curve from there so why not help people along it because you clearly have the knowledge to do that.

Eldon,

I had no intention of trying to belittle anyone. The intent of this post is to make it clear that programming is skilled work.

Not being skilled in it is not a crime, but you should not be expected to be skilled with that overnight.

And the industry as a whole should accept the fact that this is skilled work, not attempt to get along by throwing bodies at the problem

I completely understand that point but it is an issue for management and training. Of course terms like "the masses" and "X in 21 days" are belittling. Hiow else did you mean them?

The problem is that there is a purist community (especially around TDD) that whether or not they intend to or not come over as very unapproachable and will critisice any code that is not fully DI'd, mocked, SRP'd etc, etc. Now that is fine amoungst their contemporaries but the reality is that for many dev's when they are starting out full of enthusiam, constanly being critised for the failings of code rather than praised for the improvement compared to last week isn't helpful.

The vital point of Roy's blog in particular is seperate out the techniques and find an incremental approach that allows people to build layer by layer, knowledge on knowledge. That is the fundamental approach to learning that we all go through. Anything that comes out of those discussions that helps achieve it is extremely positive.

I was working closely with a junior a while ago and I started with really simple stuff. Things like: Write Short Methods. For about a week I didn't introduce anything more than that. That is not going to set the world on fire but it does prepare for when we start refactoring, introducing the odd pattern, and start testing.

"The masses" ? I don't recall using this term.

X in 21 days is a bad practice, how is this belittling?

I don't think that I am a purist, and I certainly don't call to prevent people from learning. I think that you are missing the main point of the post.

It is suppose to point out what your expectations should be. Not about how to teach people. Different topics all together.