
Why I Hate Frameworks (2005) - patmcguire
http://discuss.joelonsoftware.com/?joel.3.219431.12
======
bhauer
I find this article entertaining but ultimately stale and a reminder that as
much as we like to criticize the present, the past was not as rosy as we
remember.

I haven't worked first-hand with a web framework that I would consider
"enterprise" (and therefore encumbered by the kind of nonsense that is being
pilloried in the article) in ages, certainly at least five years.

Most frameworks I have worked with in the past five years focus on helping me
get my job done while not fussing with annoying details. That is precisely
what I want them to do.

Better yet, the most modern of frameworks do that plus have put focus on
performance, so they both solve stupid problems I don't want to deal with and
do so quickly, giving me nearly the full capacity of the server's CPU to be
wasteful/experimental/rushed with my coding style at first. Then I can
optimize later to have a high-performance system because the framework itself
is no longer the bottleneck it once was.

I love frameworks.

~~~
Justsignedup
Let's rename this post:

Why I hate badly designed frameworks with unnecessary abstractions.

~~~
jeremysmyth
I think it's more appropriately named "I don't like the word 'factory' when
used in frameworks, and I [don't|refuse to] understand how they are useful to
developers in their daily jobs."

I teach a Java web dev course that gradually works up from the servlet API
through a bunch of different abstractions. I keep a drawn representation of
the current stack at all points of the course, and keep a count of the lines
of code required to do any particular thing. At the beginning, we need about
10 lines of code to process a basic GET request, and there are lots of
explicit dependencies (inheritance, dependencies on HttpServletRequest etc.)
and at the end, there are maybe two or three lines of code, and no explicit
coded dependencies (several implicit, provided by the framework).

Once you add in a few pieces of actual work (DAOs, collections, CRUD
functionality, database connection pools, query abstraction), the code is an
order of magnitude _simpler_ when you use a framework than when you don't.

It boils down to this: Using a smaller technology stack makes for an easier
learning curve, but your day job after learning the basics involves ten times
as much code ( == ten times as many opportunities for bugs, reinventing the
wheel, antipatterns etc.), but investing in how to use a larger stack means
your day job becomes much, much easier; you write less code, you focus more on
your business logic, and you leave the dependency management and plumbing to
the framework.

Sure, you might have to use the word "Factory" a few times, but that means you
don't have to write the code to implement your object pools and collection
handlers. That's already done for you.

~~~
benjamincburns
I'm absolutely not trying to contradict you here. In general I agree with
pretty much everything you've said. However you raise something that makes me
wish to address the muddiness of the details.

> Using a smaller technology stack makes for an easier learning curve, but
> your day job after learning the basics involves ten times as much code ( ==
> ten times as many opportunities for bugs...

I think you're implying here that not having written the framework
abstractions yourself or in-house will reduce bug count. First, to be a bit
pedantic, the _opportunities_ for bugs is roughly the same over a given
feature set between coded-with-framework and written-from-scratch. The the
number of discovered and undiscovered outstanding bugs over that same feature
set _may_ be lower, but this doesn't necessarily reduce risk.

By using a framework you're making the assumption that most major bugs have
been found and fixed by the sheer volume of people testing the framework in
the wild. In a general sense, this is often a valid assumption. However this
is in no way a guarantee of good testing coverage.

In my day job we decided to make further use of an open source tool to satisfy
a particular security requirement. The tool in question has a community of
nearly ten thousand users. However, it turns out that the advertised feature
we wished to use was never really adopted by anyone in the community. Because
of this we found a major "barrier to entry" type bug that had been outstanding
for close to _four_ years, and we lost nearly a month before deciding to scrap
the effort and use something else.

Beyond bug count, it's been my experience that when framework bugs do crop up
they're more likely to be very costly or time consuming. I say this for a few
reasons. First, let's make two fairly reasonable (I hope) assumptions:

Assumption #1: Most people use frameworks to avoid having to worry about the
details for which the framework offers a solution. This usually is the main
value proposition of a framework (and the quote above alludes to this). This
means that when you plan and design your software, you typically assume that
the framework is correct. Most people don't budget time/expense for learning
the framework's internals.

Assumption #2: If the framework is battle-hardened, most of the bugs you'll
probably find are in oddball edge cases and/or are very difficult to track
down.

In the best scenario your framework code is open and you can fix the bug
yourself if need be. However you pay for this this with the original perceived
value of the framework (no need to be an expert in its inner workings), and a
_lot_ of unbudgeted time. And let's face it; when we're in a time crunch, we
don't do our best work. The probability of introducing new bugs when this
occurs is quite high.

Aside from the specific application details that you're now worrying about,
you now have new unplanned-for operational overhead. How do you maintain the
change to correct the bug? You'll either need to figure out the correct
procedures/coding style/etc to submit a patch/pull-request, or you'll need to
maintain your own fork of the framework.

Or in the other case where you're working with a closed-source product you're
just up a creek. Oh you paid for support? Isn't that cute...

I don't say any of this to attack frameworks. I use them myself quite often.
However I _do_ say this to attack the idea that frameworks make it safe for
developers to remain ignorant to the inner workings of their system,
regardless of which parts were designed/built in-house, as the fact that
something is made and supported by a third party, commercial or community, has
no bearing on its quality alone.

------
niuzeta
You should really add (2005) datemark at the end; the discussions portrayed in
the link are at best stale, while entertaining.

------
dcc1
I think its not frameworks he has a problem with but JAVA itself, I came to
the conclusions he arrived at a long time ago, JAVA doesnt save you time on
large projects it makes you drown in needless bloat and abstractions and more
worrying if working in a large team allows some members to float along easily.
but hey its "an enterprise programming language" right?

~~~
edwinnathaniel
I think you got it backward. Java could be overkill for small projects
(although I never felt that way, ever).

Large projects need a complete solution that Java has to offer (Java as a
platform, language, and its ecosystems).

Over the last 20-30 years, there's nothing out there in the market that really
increase programmer's productivity other than Java (and its GC + tools like
Maven, FindBugs, Jenkins, IDEs) and Rails (not Ruby, but Rails, Ruby itself is
"meh").

I have yet to feel that way with other tools or programming languages yet (one
of the reasons why they all failed the "mainstream" tests: only a select few
thought that their niche tools are the most productive tools ever, the rest
still aren't convinced and have yet to see big projects build on top of the
said tools).

~~~
dragonwriter
> Large projects need a complete solution that Java has to offer

I'm not sure that as true as it is popularly perceived to be; I think it may
be more true that there is such a history of use of Java and similar platforms
(e.g., .NET) in the environments that produce large systems that there is a
cultural bias to thinking it is necessary and that much of the current
experience of large systems is centered on that kind of platform.

Arguably, building large systems with less dependence on the kind of pervasive
system-wide compile-time interdependencies fostered by Java and similar
platforms and instead relying on smaller components with minimal compile-time
interdependencies integrated at runtime using well-documented communications
protocols and interaction standards -- a real platform agnostic, potentially
heterogenous, decoupled Service Oriented Architecture (without, particularly,
the return to compile-time interdependency fostered by the approach to
SOAP/WSDL common on Java and similar platforms) -- would be better for large
systems, particularly when the large systems have components that need to
adapt rapidly to changing needs.

~~~
edwinnathaniel
I wouldn't write-off SOAP/WSDL approach yet.

The last time I used it in JavaEE6, it was surprisingly very easy and pleasant
to work with.

Server-side ===========

1\. Write the services

2\. Prepare your DTO classes, annotate them

3\. Run through JDK command line utility => output: XSD, WSDL

Client-side ============

1\. Grab that WSDL+XSD

2\. Run them through JDK client-side tool utility

3\. Consume the generated code (if you use maven, you can also prepare a JAR
and make em as dependencies)

You can automate all of these via maven plugins easily for both sides.

Yes, you'd have to recompile them but it gives you a bit of
security/guarantees unlike REST. I thought my experience was not painful
enough to warrant to ignore this solution depending on the use-case/situations
(i.e.: you could always go overboard).

Compare that to some random Netflix.rb (ruby based) library that internally
relies on XPath... feels a bit shaky for me.

But YMMV and definitely it's more of my preferences than other people's.

I do aware of SOA-based solution by breaking down a big system to multiple
services with the hope of each system can be independent of others and
hopefully can be re-used easily by other services as well. The assumptions
here is that each service has its own team (of 3-4 people) that maintain such
systems. Sure, you can definitely write these services using anything you want
and you certainly invalidate my opinions on that. But there's a price to be
paid going toward this model: traceability is harder, collaboration effort
also increases, more failure points, etc (I'm sure you're aware of these).

No magic bullet I suppose.

------
datashaman
The article is from 2005, and I'm reasonably sure that nearly every geek in
the world has read it already.

~~~
danielweber
Still relevant.

I hate how, instead of being good at "technology _X_ ," employers are
requiring people to be skilled at "company _Y_ 's version of technology _X_."

~~~
niuzeta
I think we're past the era of overusage on design patterns and the dreaded
_factory factory factories?_

------
drcode
This argument basically boils down to saying "frameworks are monolithic, and
hence not flexible enough".

I agree completely with this, the best antidote to this IMHO are the ideas
from the lecture "Simple Made Easy" by Rich Hickey
[http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

He argues for an approach to framework development where all the different
parts of the framework need to be 100% independent and interchangeable.
Essentially, instead of a framework you should have 20-30 different libraries
that can fully stand on their own but can be combined to give a framework-like
result. You can call it the "Chinese Menu" approach to frameworks.

To see this approach in action, look at the different libraries for Clojure
server-side development (Ring, Compojure, etc) which consist of tiny
interchangeable libraries for specific tasks.

The new full-stack Pedestal framework also follows this philosophy (and in
fact I am sure the Pedestal designers expect large chunks of this framework to
be discarded as new approaches are tried withing their system, but the plug-
and-play nature of all their libraries allows for effortless swapping of
component libraries.) [http://pedestal.io/](http://pedestal.io/)

~~~
stcredzero
_> tiny interchangeable libraries for specific tasks._

So, the UNIX folks had a good idea, then.

------
rheide
Today's version: Hammer Factories as a Service.

------
gonnakillme
Jesus, the casual misogyny in this article is staggering.

~~~
BillyMaize
misogyny - Hatred of women. How does that have anything to do with the
article? You must mean some other word.

~~~
gonnakillme
Sorry for being unclear -- I'm referring to these parts:

> And, if you want to kill your ex-girlfriend, there's really no substitute
> for a ball-peen hammer.

> (Maybe they've never had ex-girlfriends. Or maybe they killed them with
> icepicks instead.)

~~~
VLM
Its not like the story would have been any less unsavory if he was talking
about his boyfriend.

My gut level guess, is this being an extremely old argument, the headline for
this one was adjacent to a Reiser headline, so its more of a bad taste style
of the times than a long term trend or hidden social bias.

~~~
gonnakillme
It /would/ have been less unsavory if he were talking about his boyfriend,
though; women are exposed to violence (especially in relationships) in a way
and at a scale that men just aren't. The way this is presented -- of /course/
everyone can relate to wanting to kill their ex-girlfriend -- is especially
gross.

I'm not sure what Hans Reiser has to do with anything and it's a little
strange that you brought him up. Wikipedia says Nina Reiser's disappearance
was in 2006, a year after this post was made.

~~~
VLM
Thank you for the second paragraph you are completely correct and I was wrong
about the chronological order of those events.

On the other hand I think we are going to have to disagree on your first
paragraph. I think you have a perfectly good axe, I just wouldn't grind it
there. That component of the original article sucks as a writing strategy
without bringing male/female drama into the picture clouding the overall issue
of using images of violence inappropriately. I wouldn't downvote you for it,
but someone apparently is doing so, which is too bad.

------
ebenoist
What is with all the casual yet incredibly violent references to violence
against women? Do we really need that in an analogy about software frameworks?

------
badman_ting
Oh boy, an overwrought analogy. Everyone loves those.

~~~
tootie
Comparing frameworks to hammers is the completely wrong analogy too. A
framework is, you know, a framework. Like insetead of buying 30 different
hammers to build a framework, you buy a framework. Then you don't need a
hammer. And the framework has slots for your fixtures that use standard
fasteners so you can rely on fewer hammers and screwdrivers. Put up some
siding and your house is done.

~~~
brudgers
In Alabama we call them "trailers."

~~~
stcredzero
A trailer's not a framework, it's more like shrinkwrapped software.

------
mcintyre1994
The issue with this approach is we don't only need tools, what about when my
tool factory factory factory creates a drill factory factory to build a drill
factory so I can build a drill.. but then my drill needs batteries? Now I need
to build a battery factory factory factory to build an AA battery factory
factory to build an AA battery factory so I can build AA batteries.

But that approach seems absurd, what we really need is a more generic factory
factory factory factory that can produce tool factory factory factories and
battery factory factory factories, as well as all the other factory factory
factories we might need in the future!

(On another note, try reading that fast ten times)

------
banachtarski
This sums up more or less why I ditched Rails altogether.

~~~
loupeabody
Funny enough, one commenter on this article advocated Rails:

"I don't want to start yet another religious war, but for a nice respite from
the complexities of J2EE frameworks, check out Ruby on Rails. I'm playing with
it now and it is a pleasure to work with."

I was actually surprised to see this is from 2005 too...

~~~
astrodust
It was frameworks like the ones Joel was railing against that inspired Rails.

A framework should help you do your job, not get in the way.

~~~
brianmcc
(post was by BenjiSmith, just on Joel's site)

~~~
astrodust
Ah, good point.

------
programminggeek
All frameworks that start out as small tools are destined to become the thing
that they hate if they ever get popular.

~~~
nathan_long
All projects written without frameworks are destined to re-implement
framework-like features, but not as well, if they succeed.

(My statement isn't really ALWAYS true, but neither is yours.)

~~~
coldtea
> _All projects written without frameworks are destined to re-implement
> framework-like features, but not as well, if they succeed._

Of course they will implement framework-like features, that's inevitable.
You'll still need routing, authentication, etc.

The win is that they'll implement them for their SPECIFIC use case, and only
as much of them as they need, instead of having to accept the whole garbage
that comes with a framework.

And you can cherry pick the best libraries for the cause, enging with even
better ones that what any framework offers built-in.

------
stcredzero
One word: Java. By making Java a bit less dynamic, its creators could add in a
bit of static typing and C-like syntax and market it very effectively. (Not
what they intended, exactly, but what ended up happening.)

But what happened, is that Java lost just enough power and abstraction, so
that the cost-benefit of burgeoning software tooling was still a net win. What
Java lost in power, it made up for by writing more code. This is why Java web
application servers, Java IDEs, Java messaging middleware became these
lugubrious and unwieldy monstrosities, while we in the Smalltalk camp marveled
at how we had equivalents that had start up times and enabled edit-test-debug
cycles orders of magnitude faster while being comprised of less code -- and
yet we were the ones saddled with the "legacy" label and the reputation of
being slow. (And entire kinds of tooling like Spring and Maven -- just
entirely absent and unnecessary!)

Summary: beware of the situation where something is hyped, but you still wind
up with more tooling and writing more code than you would have otherwise.

Most likely, you can do it with less code.

I've been picking on Java here, but this applies to the majority of cases. It
even applies to some things in Smalltalk. What are you really trying to
accomplish, and can you get most of the same effect with less?

------
gwu78
This is great. I was just thinking about this phenomena when I woke up this
morning.

In the early days there were general purpose toolmakers. And tool users had to
develop the skill to use general purpose tools. They could then tackle a
variety of tasks.

Today it appears that the most effort goes to making special purpose toolkits
(e.g., frameworks). The only "skill" that the toolkit user must develop is
mastering the toolkit. But the kits are enormous, the documentation is
enormous and the time commitment is, relative to the number and variety of
tasks she will be equipped to tackle after mastery, enormous. I'd venture to
guess most users of frameworks only use a small fraction of the toolkit. Hence
they can only tackle a small fraction of the tasks that the toolkit could
permit them to tackle were they to master all of it. To learn how to use every
feature (every tool) within these specialized kits would seemingly take a
"lifetime".

Is learning a "framework" worth my time? What happens when the tasks change
and the toolkit I've mastered is replaced by a different one? What if I spent
my time learning how to use the general purpose tools (still available on
every computer running UNIX) that can be used to build special purpose
toolkits instead?

Measured in terms of learning and skill development, maybe the greatest
benefactors of frameworks are the folks that build them. That is a thought I
had. Presumably they must themselves know how to use more general purpose
tools. Thus they can build frameworks of more specialized tools. If this is
true, that is a skill that is worth the time investment, in my opinion.

Joel on Software was a great forum. I only wish Joel was a UNIX programmer.
His frame of reference always seems to be Windows.

------
kops
The word "portlet" is like a huge warning sign to me that reads "run...like
hell....while you still can...."

------
AndrewDucker
It's true that if you want to build a spice rack then you don't need a factory
to build factories to churn out hammers.

But if you're building a city then the chances are that you don't want the
people who furnish each flat in it to have to worry about how the plumbing is
done. You want them to be able to concentrate on just their bit, and let the
infrastructure work around them,

And that's when these frameworks come in handy - when the people churning out
CRUD code to process data don't have to worry about what the message queuing
system is, or how their code is instantiated, or where it's going to be used -
they just have to wire up a couple of standard interfaces, and make their
specific code work.

Someone else will have set up the configuration for them (whose job it is to
do just that), and they can get on with their speciality, rather than trying
to fashion their own hammers out of rocks, logs and twine.

~~~
VLM
"they just have to wire up a couple of standard interfaces"

Which change constantly over time. I started playing with Rails in 2006 and
refuse to touch it ever again. Oh god the tragedy when rails upgrades and now
I have to figure out why the code no longer works. Perl CGI was never, ever,
even in the bad old days, nearly as bad as that.

Rails is awesome for development. The rest of the software lifecycle, well...
Lets just say it is never allowed to leave development. You're one apt-get
intended to patch a security hole, away from a significant rewrite project. I
hate it.

Someday, when its totally obsolete, it'll finally be stable enough to be
"enterprise grade". Till then I've had enough.

~~~
domness
I don't think I've had an issue like that over the past couple of years in my
Rails career.

I'm sure you should have probably understood why your code 'no longer works',
perhaps some bad Ruby/Rails programming practices?

~~~
VLM
Almost certainly. And that's another reason I can't stand it, its a my way or
the highway culture rather than there's more than one way to do it culture (my
mistake for hanging with the wrong crowd), and its marketed as a tool for
noobs to quickly ramp up a simple CRUD plus a bit more.

Its marketing doesn't match its design. Its a tool for experienced experts to
work slightly faster using the One-True-Workflow which they already know. On
the other hand, most books, online tutorials, etc, show it as a noobs
playground. Its like taking the kids to a neighborhood park that turns out to
resemble an Indiana Jones movie set.

I had zero ruby experience when I started fooling with RoR in 05, 06. All
rails did was get in the way of developing those language skills. Training
wheels on a Harley Davidson, something like that.

Write once, upgrade never because it'll stop working and as a noob shielded
from the cold hard world by the framework, you won't have the experience to be
able to figure out why. What a pain. The whole experience, just suffering.

Off the top of my head, around 05/06 going in as a complete ruby and rails
noob, there was no noob-obvious handholding way to handle many-many CRUD.
Things have in fact probably improved quite a bit since then. The problem is
with a one-true-path culture, everything has to be rewritten to fit the
enforced style of the day. And frankly for some meaningless intranet "CRUD
plus a little more" app thats now become somewhat biz critical, I don't want a
life of permanent rewriting.

Ah, whatever, just ignore my ranting. My experience has been horrific and
it'll color my judgment. I'm sure for everyone else its all candy corn and
unicorns and balloons all day long, and will continue to be so. I'll just use
something else.

~~~
mattgreenrocks
I think Rails is wonderful, but it's not for me. It's explicitly designed to
shut down many design decisions because they were made a priori by DHH. Don't
want to co-mingle persistence and domain modeling? Too bad! Tie yourself to
the ship and get on with it!

I realized the other day that Rails is designed for Internet time: ship as
fast as possible, see if it sticks. If it does, then needing to re-write every
few years is assumed to be no big deal, as, presumably, it is succeeding.

I view rewrites as a fundamental failure of design. I should be able to evolve
the domain model independently of the UI. Only when there are massive,
breaking changes in the scope of the application ("we're going to sell video
games instead of show classifieds!") is a rewrite truly necessary.

But, IMO, industry hates design because it alludes to the fact that
programmers are not easily replaceable. So, it pushes a new framework or
language every 2 years to keep people hopping around, solving the same problem
over and over. Meanwhile, it fails to train those people in the (mostly
timeless) ways of solving problems reliably. And devs lap it up, secretly
hoping it will fix all those icky maintenance problems they're starting to run
into.

------
mehulkar
I've had this conversation before in different terminology. I was concerned
that a majority of service based businesses were building castles in the
clouds and creating a bubble. Naval of Angellist recently tweeted something
similar [1]. Essentially, it comes down to this: the more layers of
abstraction you build, the farther you get from solving real problems. I guess
this is the epitome of consumerism though.

[1]
[https://twitter.com/naval/status/360890615896092673](https://twitter.com/naval/status/360890615896092673)

------
cmicali
So what is the right java web framework today? Play has gone down the scala
route - is there really another rails-like web framework that today that would
do what the author is asking?

~~~
bhauer
Rails-like is a confounding term. If you mean something as comprehensive, I'm
not sure there is quite an analog. Although I personally don't usually want
something as comprehensive.

If you mean something that is easy to get started, deals with the most
annoying stuff, and gives you the fundamentals to implement an application,
then I think there are some good options.

Of the Java frameworks we've tested [1], if you are ruling out Play-Java
(because of a real or imaginary Scala design preference; I'm not judging
that), I personally enjoy the coding style of Rest-Express and DropWizard.
Check out the Rest-Express [2] and DropWizard [3] multi-query test
implementations for a quick insight into their coding style. (Note the Rest-
Express test was contributed by that framework's author.)

I'm not sure if this really answers your question, but I think it does speak
to my earlier point in this thread that modern frameworks solve the problems I
most care about and also (happily) tend to do so more efficiently--with
respect to server resources--than the frameworks of a few years ago.

[1]
[http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db&l=3k)

[2]
[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/restexpress/src/main/java/hello/controller/MongodbController.java)

[3]
[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/dropwizard/src/main/java/com/example/helloworld/resources/WorldResource.java)

~~~
cmicali
Thanks!

Nothing against scala specifically, just using Play-Java (which we are) means
you are bound to using sbt and when debugging into play internals you are
looking at scala instead of java.

DropWizard is fantastic, will check out rest-express. I think the thing I miss
from both that you do get in play (and rails) is the front end templating,
assets pipeline, and useful assorted bits tailored to quickly building a
html/js/css/api web app.

------
ohwp
Ofcourse the message here is 'too much abstraction'.

There are loads of bad frameworks that want to be too smart and too clean. I
mean, there is nothing wrong with writing HTML. But I've seen stuff like:

    
    
       $output .= $framework->dom->returnInputElement('text', 'name', $initValue, $options);
    

That's nice and all but when it just returns the element without any extra
functionality I think its just a waste of code and resources.

~~~
dclowd9901
A framework like this would probably scaffold the inputs for you based on your
model structure, in which you do get back that you don't have to write boring
ass crud stuff. Great for doing admin pages.

But for consumer facing stuff, you should probably abstract to something that
templates (HAML, mustache, etc).

------
epynonymous
this is most likely a rant on jsp and servlets (cringe), judging by the time
period, struts was probably used in combination with these technologies which
had to run on some overly expensive app server or tomcat, and needed to
include the j2ee sdk (java 2 enterprise edition for all you youngins) even if
you're just using servlets, j2ee and ejbs were a whole other ball of mess.

i can relate, writing apps in rails, django, etc is much better than what was
available back in the day (8 years ago!) for java side, spring was just
starting to emerge around that time if not later which gives you a pretty
comparable experience to rails.

------
zzzcpan
Here's the problem with frameworks: unnecessary complexity. Or YAGNI, as some
may call it. This complexity leads to lots of incorrect assumptions about
internal workings of the system and therefore bugs and security holes.

------
swah
Very sweet piece from Benji Smith, reminds me of Steve Yegge's "Execution in
the Kingdom of Nouns"...

------
PDegenPortnoy
"general-purpose tool-building factory factory factory" Heh.

------
freejack
I lost interest at the tasteless killing your ex-girlfriend joke...

~~~
coldtea
Yes, god forbid a blog post has any humor to insult puritan values...

------
dustingetz
these articles are what happens when a 24 year old peon engineer criticizes
the industry accepted best practices of the time as determined by veteran
architects with eight times the experience

edit to add some anecdotes: scalac and javac are written by the same person.
The founder of Relevance, the company that funds Clojure development, wrote a
book in 2006 about spring and hibernate.

~~~
mwfunk
Just so nobody gets confused by this comment, Joel was 40 when he wrote this,
and was the program manager for Excel in the early '90s (> 10 years before
this was published). So just to clarify, this was not written by a 24-year-old
"peon engineer". I don't necessarily agree with what he wrote, but he does use
capitalization and punctuation, so he's got that going for him.

~~~
dmiladinov
Now I'm confused - I thought Benji Smith wrote this?

------
tazsingh
Were you hammered when you wrote this?

