In my investigation of rails-style development I’ve come up against a meme that has been circulating out there forever. “Real Developers”, it’s said, take to MVC / rails environments like ducks to water. It’s only the baby noobs who known nothing but ASP.NET who find themselves lost — because they aren’t deeply intimate with the HTTP protocol itself.
It reminds me of the old days when it was said that “Real Programmers code in assembly language”. In the face of pragmatic reality that meme gradually morphed into “Real Programmers know assembler” and can use it in appropriate circumstances. Still later, the “Real Programmers” used C, and so forth. In some ways this mentality has passed into legend, but it keeps reinventing itself periodically. Sometimes it expresses itself as more of an anti-meme, in terms of what it’s against rather than what it’s in favor of. The VB folks, for example, have taken a lot of this kind of abuse over the years.
To my way of thinking, a “real developer” is someone who consistently produces quality software systems that delight customers. “Real developers” do this in spite of whatever handicaps happen to exist in their world. They know that no technology, platform, API or software ecosystem is perfect, but they know how to leverage the strengths of what they are given to work with to produce excellent results. And if they don’t know, they can admit it to themselves, and learn quickly.
MVC fans can look down on people who use ASP.NET because ASP.NET developers don’t necessarily know much about the arcana of web protocols. I grant you this will increase the learning curve for environments that require them to know such things. But personally I don’t see an inherent problem in abstracting away the details of HTTP, POST, GET, headers, cookies, and so forth, for our daily work. How is that any different than, say, Java abstracting away CPU registers? Do you have customers who are willing to pay you to code in assembly language so that as to wring out more performance than Java? I didn’t think so.
In my experience, devs who are “into” low-level protocol hacking don’t necessarily grok business realities, and may even take refuge in the esoteric in order to avoid the concrete — they don’t like coping with the “wetware”. It’s the same reason people go into medical research rather than clinical practice. They want to avoid those damned patients and their messy, unpredictable problems and needs. Test tubes are much more predictable.
Clients want problems solved in their business domain. So if ASP.NET takes care of handshaking with web servers in such a way that it frees up developers to concentrate on solving business problems rather than re-inventing the wheel for managing HTTP traffic, so much the better — all things being equal.
Returning to my definition for a “real developer”: what about ASP.NET might frustrate such a developer from delivering great software systems that delight customers? I don’t think it’s the useful abstractions that ASP.NET provides; it’s just perhaps in some cases the implementation of those abstractions. And even then, the problem isn’t immediately apparent, and isn’t a big factor in all kinds of projects.
Do “real developers” have tons of curiosity? Yep. Do they learn things for the pure joy of it? Sure. Is knowing what’s going on under the hood going to make them better rounded and more effective? Most definitely. But if they don’t need to think about low level protocols on a daily basis, or if the minutiae they’ve chosen to learn in their spare time happens to be in a different area, I don’t think that in itself reflects badly on them, either.
Great software can be produced with a variety of languages, tools, and APIs … with varying degrees of pain in different phases of design, implementation and maintenance. Great developers — “real developers” are behind all of those solutions.
{ 4 trackbacks }
{ 23 comments… read them below or add one }
What a crap post! Where’s the rant on why language X is better than Y? or some “wonderous new insight” as to why Ruby/Haskell/Functional Programming “Is The Future”(tm).
C’mon, you sound like you can reason and think. You shouldn’t be writing a blog you should by lying in a gutter somewhere showing signs of being trampled over by the idiots that write blogs on software and have a demonstrable lack of skill in writing and software dev.
But seriously, thanks for a sensible post. Made a change from the usual dross I read while waiting for the current project to compile.
ASP.NET can do quite a number of things that RoR cannot. I have used a true MVC implementation with ASP.NET and find that I am very productive with a greater degree of freedom compared to RoR. Dont get me wrong, I think the competition provided by RoR is great and its even changing some of the prospective tools coming out of MS. A couple of days ago I posted a note on how my own code base compares against the features of some of the other popular stacks.
While I admire Jakes sense of the sardonic. It made me wonder if he isn’t referring to bloggers who have to “izer” or “crunch” into their blog titles, or use the word “mashup” to refer anything other than a concotion of taking a perfectly good legume and mashing it up into a creamy consistency.
The fact is that there are “techno-bigots” everywhere you look. I have to be honest and admit I was one of those “I can endian swap 32bit words in 5 cycles” crowd ( this is hailing back to the i286/386 days, of course ).
I’m probably even accusable of being a little anti-Visual Basic biased. Probably because of all the Computer Science courses at college where most “common habits of VB programmers” were expressly “NIEN ! VERBOTEN !”.
So while I do enjoy using Rails ( it IS after all, just a tool ), as Bob aptly puts it, there is absolutely NOTHING wrong with abstracting away things. What ? You didn’t KNOW that Ruby had a heart of C ? Where have you been ? Even Matz’s cat knows that.
Oh, and before I go. To those of you xRuby folks, and you know who you are. I take general offense to you, Ruby on Java indeed. Why don’t we just put Peanut Butter and Jelly on Toast, and call it a sandwich ? I bet if we did that, then all the Reuben and Pastrami on Rye bigots would start coming out of the woodwork then.
So remember, when thinking bytecode, remember it’s all BYTE’s in the end, and no matter how optimized YOUR interpreter might be ( Yes, I’m looking at you Java ), it’s all going to be reinterpreted by the CPU microcode ANYWAY. So there !
“Only Real Programmers program http/ajax in Ruby”. Bah !
What a great post! I agree that too many developers complain about the tools or the pros and cons of a particular language and miss the larger picture – that what you need to do to be a “real developers” is to solve a concrete problem.
If I could wrap everything you just wrote into a slogan it would be something like: “Real Developers Don’t Bitch. They Code”
Fantastic post. Thanks for pointing out that the RoR crowd is just a bunch of silly fan-boy wanna-be programmers that think they are sooo superior. We all know the the real work on the web is done with ASP.NET and you’re right to dismiss the whiners who don’t understand that.
Bob responds: Thanks for the kind words, Rusty, but I wasn’t really trying to be that hard specifically on the RoR folks, even though some of their attitudes prompted my comments. There is no shortage of highly competent RoR developers. The real problem is the elitist snobbery everywhere, including the .NET world. Even within the .NET world (witness C# snobbery toward VB.NET). What I hope this post will do is not feed this internecine warfare, but help us realize that it’s about as dumb to think you’ve built a Cloak of Invincible Superiority out of your favorite language or platform, as it is to think you’re a better man because you’ve got a big — well, you know.
Sorry to go a bit OT…
> It’s the same reason people go into medical research rather than clinical practice. They want to avoid those damned patients and their messy, unpredictable problems and needs.
I don’t think people go into research for the same reason people dig deep into arcane technologies and complain when they have to come out. I don’t think it’s just to avoid “customer interaction”. These two pursuits are not very similar at all. I don’t think there’s a position or practice in the medical field analogous to that protocol spelunker, though maybe the titular character in the TV series “House” approaches it. But there is a position in Computer Science that is analogous to medical research: Computer Science research.
And the reason people go into research is that they are not content to use existing tools to solve the same old problems day-in day-out. Solving a problem once is interesting. Solving a problem repeatedly, even with small variations, gets tedious. Research allows one to solve a generalized problem, representative of a whole class of problems, then pass that knowledge on to others to make into useful solutions to every-day scenarios.
Researchers are not opposed to learning new and useful technologies, but they are also not content just to learn something that _they _don’t already know. They want to learn and discover things that _nobody_ knows yet, including new classes of problems that those in the trenches don’t even recognize yet.
At least that’s why _I_ would go into research. And that motivation would never drive me deep into the arcane technologies that stave off customer interaction.
And as far as those protocol spelunkers, trying to get away from customer interaction… There’s probably a place for them. Sometimes they end up as code-monkeys, or in admin/support roles. I think there is a place for people who just want to be the absolute best at dealing with a particular set of technologies.
Anyway, largely quality post. But I’m not sure that either researchers or these tech-heads (for which we don’t really have a proper name), deserve the implied disdain.
Bob responds: Perhaps I over-hyperbolized — not everyone who goes into the research side of things does so to escape human interaction or negative feedback. In some cases, quite the opposite. But I am acquainted with one medical researcher who, when his pet new treatment for a particular disease did not work out in the real world, was heard to mutter bitterly, “those goddamned patients!” I am unapologetically disdainful of that sort of attitude, but did not mean to imply that it’s a universal affliction of all technical specialists and researchers.
I agree with your point about abstractions. But we need good abstractions. ASP.NET abstracts things in a way that sucks.
ASP.NET hides HTTP in an intrusive way with dirty Javascript and hidden fields just to be capable of designing web apps in a VB6-like fashion.
Bob responds: Yes, we can have an intelligent debate about those questions, which is why I’m looking at MVC-style alternatives, to see if in fact it’s overall a better, less “leaky” set of abstractions. However, I also don’t see what’s wrong with the ability to design web apps in what you call a “VB6-like” fashion, so long as it works and has long-term maintainability. That is actually not at all specific to VB6; it’s been a feature of Delphi and other non-Microsoft environments for many years. There is no glory in doing things by hand if they can be effectively done in a visual manner. I wouldn’t dismiss visual design tools so readily!
I apparently can’t seem to get your trackback service to pick up. So here’s a link to a blog post referencing this one: http://themicrobusinessexperiment.blogspot.com/2007/03/on-real-developers.html
“…as it works and has long-term maintainability.”
But that’s the key! Many ASP.NET programs can NOT be designed to provide maintainability on a large-scale project, at least not without awful, complex steps that stem from some very bad decisions made by the ASP.NET crowd (control IDs getting morphed… what the hell am I supposed to do with my stylesheets?).
Bob responds: Ah, you noticed that phrase! It was in fact there for a reason. Design-in-the-large is where ASP.NET begins to (please forgive me) come off the rails. And that is why I am looking at MVC. That said, most ASP.NET designs could be much better than they are, largely because people use rapid prototyping features like drag-and-drop database connections on forms, and somehow that stuff never gets out of production systems.
The other thing this post is way off base about is declaring that MVC has some magical connection to HTTP. Model – View – Controller has long predated web development, it is a pattern for any kind of user facing software.
I work in both Rails and ASP.NET and I can tell you that both frameworks are pretty opinionated – i just prefer the Rails opinion. ASP.NET forces some strange abstractions on you that divorce your mind from how web interactions really work, I find rails is a good mental bridge between a good abstract domain model and the actual page interactions.
The other thing that really annoys me with ASP.NET is that you have no idea where to look for code – maintaining someone elses ASP.NET web app can be hell. You might not like rails’ set up but at least you know where to look when you need to make a change.
Bob responds: ASP.NET’s abstractions are not strange to someone who wants web development to be more like desktop development. The question is whether those particular abstractions are too leaky and whether that is inherently so or just because it’s not a good enough design (or not the right design to accomplish that goal). As for the MVC / HTTP connection, I search my post in vain for such a “declaration” although I admit I probably didn’t have to mention HTTP at all. MVC is just closer to the metal in a sense … requiring you to think more in terms of the requirements of web protocols and standards which many feel is a distraction from the actual business problem a particular project may be attempting to solve. I suspect this is both good and bad. I don’t claim to have a fully-formed opinion as yet, because I haven’t explored it thoroughly.
Dare i suggest that the languages and tools that offer “do-it-all” mega-abstractions such as ASP.NET attract more than their fair share of “non-real” developers (the ones who can’t be bothered to learn, don’t look critically at their own work, and really do believe that one language and IDE is all they will ever need) precisely because they have been heavily marketed at mindless drag-and-drop forms monkeys on the vacuous promise that they won’t need to learn anything new?
Bob responds: I think that’s a valid criticism, although I think the real problem is that the subliminal marketing messages you describe appeal to pointy-haired managers who in turn hope to hire less capable / less costly developers. There is certainly a huge tendency to think of developers as “code monkeys” who need only know a do-it-all, silver bullet tool. Treat them that way, and it’s what you get.
There are different ways to abstract details. Some make sense, some don’t. Good abstractions make things easier while keep you in control. Bad abstractions make things easier while abuse you by imposing restrictions on you. Unfortunately, ASP.NET’s approach to abstract HTTP, HTML, … just doesn’t make sense for ‘REAL PROGRAMMERS’ who don’t want to be imposed by the restrictions.
IMHO.
Bob responds: Maybe the real problem is the difficulty of taking ASP.NET’s higher level abstractions off like the icing from a cake so to speak, so that you can deal with things at a lower level when it makes sense. At any rate, the issue of control is an excellent point. Back in the day, I resisted SQL precisely because I feared that loss of control. I was used to procedural DMLs and did not want some high-level query optimizer second guessing my intentions. The difference was that SQL turned out to be a very good abstraction, so good that it often out-performed my precious hand-crafted code. So I changed. I doubt anyone else here is still using XBase or Btrieve except for legacy systems … right?
I don’t think this post is actually about being a real developer. Personally I feel that a discussion about what makes a developer a “real” developer should be agnostic of platform, language and technology.
Bob responds: I am not sure you read all the way through the post, especially the close. That said, you are correct that the topic could be discussed without any concrete examples but I think that would make it more of an academic exercise and I am hoping to engage people where they are in ways that might actually provoke thought and change.
Hmmm… No mention yet of Monorail or other development frameworks for ASP.Net such as DotNetNuke ( DNN is fun! )
If you don’t like ASP.Nets abstractions, it seems like there are more than a few frameworks available to apply MORE abstractions to your development style.
Just my 2 cents to muddy the water…
Bob responds: I actually started this post mentioning my investigation of “rails-style development” with a link to my previous post that discussed Castle MonoRail. As for DNN, well, one person’s fun is another’s torture. I actually have a post coming up about that one. Let’s just say for now that yes … DNN adds still MORE abstractions on top of ASP.NET.
Just to clarify, though, if you’re calling DNN one of the “other development frameworks for ASP.NET” then you are suggesting that MonoRail is also a dev framework for ASP.NET. I suspect the folks over at Castle would take some exception to that. MonoRail is a dev framework that runs on the .NET CLR and class libraries and offers C# project templates for developing in Visual Studio, but to my knowledge it completely ignores the ASP.NET infrastructure such as server controls.
Great post. Thanks.
I have a gripe on the MVC vs. ASP.Net debate. Its that word versus. The whole debate assumes that ASP.Net is not MVC when it clearly is. ASPX is the View, ASPX.CS is the controller. Granted, you have to add your own model, but that part is just good practice.
The other problem is that nearly every discussion I have read of MVC covers only one form of MVC (at least for web development). I have tried several MVC frameworks for PHP and they all seem to take the following approach:
1. Build some template with code and markup mixed in, often with some sort of additional templating language, other times just using context switching. ( )
2. Build your controller. Usually has a default method that gets run on all calls to the object. Each method of this controller will be an action, associated with a URL.
3. Build a router at index.php. Take in URLs of the form http://mysite.com/index.php/class/method/id. Instantiate the class, and call the method with the id.
4. Add Models as needed.
To my mind, this approach is terrible. It is counterintuitive: to have multiple URLs pointing to the same object is just silly. It is also abstraction for its own sake. Each of those methods could be its own script. If you need default actions, the use include files. It all assumes that every page is going to be extremely simple (at least on the server end). Another supposed benefit is that you can group related tasks together. For example, you could have a user module, with login, logout and get_details as methods. OK, fine, but isn’t that what the model is supposed to be for? I get the impression that MVC was created initially for Java, in an attempt to alleviate some of the excess boilerplate. It is totally unnecessary in scripting languages that don’t need all that boilerplate. From what I understand, Rails takes the same approach, which is why I haven’t tried it. The only way this approach can work reasonably well is if each of your methods is small, with most of the code is in the presentation layer, and most of the actually processing happening on the client.
IIS takes care of the routing for you. The Designer/HTML view lets you design the view, completely free of any code (presentation code, or business logic), and because the view is compiled to code, you have direct access to every control on in the view. .Net certainly has its problems, but it is a heck of a lot better than the standard MVC approach.
Bob responds: Aaron, in a way, you can regard the code-behind to be a controller, but the fact that it is married to a single view (the form, or perhaps a usercontrol) means there is near zero flexibility in deciding what view will represent what controller.
MVC vs ASP.NET was not really the main thrust of this post; the tension between the two camps was more of a concrete example for discussing how religious wars distract from what constitutes a “real developer”. That said, I do appreciate the points you’ve raised as they are something to consider as I sort MVC out for myself …
I think that was a great post. Personally, I hate producing real-world software meant for the end user and love protocol hacking. Why? Because the end user environment is unpredictable, exactly as you stated. It’s frustrating and mundane.
A related example is a personal project of mine, which involves a physics simulation backend and a web frontend. I spend all sorts of time developing the physics engine, but I’ve yet to get more than one or two use cases implemented on the front end, because dealing with workflow, page layouts, input validation, etc. is just infuriating. I hate it, and if I had to do that all day, I’d find another career.
In other words, you’re right ;) Real developers aren’t protocol hackers. Real developers are those who are able to get the job done. Real developers provide real solutions, via whatever means is most beneficial to the customer, at a cost reasonable to the customer.
As for myself, I’m fortunate enough to work for company involved in network switching hardware, so I get to protocol hack for a living. Sweet!
Bob responds: You rock! In my experience not many people have the self-awareness to objectively evaluate themselves as you’ve just done — and find a place where you can be happy. Too many people with your skills and talents take positions they hate and it shows. If you ask me, we need more guys like you watching over those protocols!
On the one hand i consider this a great post and agree with most of it, but on the other hand i disagree on the comparison between assembler and the basics of web development (HTTP/GET/POST/Cookies) and that someone working in this environment shouldn’t know about it.
When abstracting, the level of abstraction shouldn’t reach a point where you can’t handle at least the next step “deeper” anymore. When you use any framework, you should be able to handle the language it is written in. When you use a library for a task (e.g. XML manipulation), you should be able to work with XML manually (even if this means Notepad). Know the tools for your job, leverage them to be more productive – but stay on top of them. Don’t let yourself get controlled by them because they are actually “smarter” than you are.
The reason for this is control, understanding and most important debugging. Some people are lost when their framework has a bug, some people don’t understand the workflows even close to them because their tools do some “magical step” on the way.
Just a minority needs to know about assembler, or TCP/IP, or stacks, or memory management – but just because you have a dishwasher you shouldn’t forget about how it is to wash them by hand (admitted you don’t need to know how to potter a mug).
Bob responds: Thanks for the excellent comment — very well thought out points and great analogies.
There may be a way to recognize “real developers”:
http://dotmad.blogspot.com/2007/03/real-developers-have-big-egos.html
Just a note: ASP.Net is the whole .net infrastructure/bridge/web hosting runtime. What you mean is WebForms.
And yes, MonoRail runs on top of ASP.NET (it’s just a custom handler), just like webforms runs on top of ASP.Net (it’s another handler associated with the aspx extension).
Bob responds: I stand corrected — thanks for the clarification!
I think there is something fundamentally wrong about someone who does not know HTML claiming to be a web developer. What is the difference between the arguments you are mooting and saying “I don’t need to study medicine.I just need to know how to dispense aspirin?”
Bob responds: I never asserted that web developers shouldn’t know HTML, which would be taking my arguments to an absurd extreme. Web designers who don’t generally claim to be developers, even have to know HTML. It’s all about finding and working at the right level of abstraction, not about the fallacy of turning development into a production line operation — which I have written against extensively before.
Sorry for going off topic again, but I need to respond to this.
The problem with this statement is that it assumes that such a decoupling is necessary (and possible) in most situations. How many times have you been working on a page, and honestly wished you could use a different template? Now think honestly for a moment: If you did, how much of that code behind would have simply crept into the template? How thin would that Controller be afterwards (especially after you separate the data access stuff into the model)?
Decoupling the view from the controller is one of those things that sounds nice in theory. But, none of the examples I have read actually show you how, and several sites actually admit that it is impossible (or at least impractical) most of the time.
That being said, flexibility is a great thing. However, I think that mixing code into the markup, even if it is just presentation code, is a step in the wrong direction. If there were an MVC framework in which the view was compiled down to a class, which gave you programmatic control from the controller, I would take a look at it. You could define a default view for the controller, and override it as necessary. Something like this:
this.View = LoadView("some_other_view");
// Code control of the view
this.View.dgSomeGrid.DataSource = this.MyModel.GetSomeDV();
this.View.dgSomeGrid.DataBind();
Until such a thing exists, I am not willing to give up code based access to the view for some theoretical benefits. Even if you can provide an example where you can use multiple views for the control, I would be hesitant to use it until code is removed from the markup.
Bob responds: I’ll concede I was throwing out a theoretical argument because it’s one of MVC’s selling points and it does appeal to one’s sense of design elegance. You are absolutely right, though, that it may not matter nearly that much in actual practice.
Real developers use patterns, regardless of language. Programming in C# doesn’t make your design Object Oriented.
The MVP pattern (a variation of MVC) is a very useful pattern to separate Form(no pun intended) from Function..
The idea is that a UI object should be responsible for UI and only UI. It is a portal to Input and Output and the only thing it should be in charge of is rendering.
You can test the Presenter’s logic without having to fire up the app.
MVP is highly useful in a 3 tiered web application, which you really should be doing with ASP. Writing all your data access code behind a button click is a nightmare to test and maintain.
Bob responds: I believe that anyone who is thoughtful enough to learn from their mistakes and lazy enough not to want to work harder than necessary — both traits of “real programmers” — will gravitate naturally towards patterns like MVP and MVC. What works in the other direction — towards what you call “all your data access code behind a button click” — are deadline pressures, lack of appreciation for best practices from management, and other forms of technical expediency.