Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Patterns, Purists, and Sinkholes

Before I was a geek, I was a Geologist. A Geophysicist to be precise – but mostly I just tell people I was a Geologist. I worked a lot with environmental cleanup, but I also spent a lot of time doing what’s known as “Geotechnical” work – the stuff that happens before buildings are built and holes are dug. It can be kind of boring, but it’s crucially important.

One day I was sitting in our lab with some dark Bay Mud in a crucible, slowly adding water in measured doses and then pouring the mud through a screen and weighing out differences. I won’t bore you with the details – I’ll just tell you that I was 23 and cranky that this is what my career amounted to – a bunch of rigorous nonsense where I got to weigh mud.

I started complaining and mumbling and my boss (who was a patient to no end) filled me in on some details:

What you’re doing, Rob, is measuring the amount of clay that’s in soil at this site. The water you’re using dissolves the clay, and the screen removes the sand from the clay/sand slurry that you’re mixing in the crucible. We need to know how much clay is in the ground so we can know how much it will swell in the winter when it rains. This will keep the building from expanding/contracting and falling over into resultant sinkholes.

I won’t bore you with the rest. Suffice to say this: building things has been around for a long time, and it took a WHOLE LOT of buildings falling over before some smart guys (let’s call them purists) got together and said “we should do it this way”. They then convinced their local governments and boom, the building code is born.

Geek Building Codes
My house is built on volcanic clay that’s been amended to some percentage of clay/sand/aggregate so that my house can stay standing for at least 50 years (not counting hurricanes). I’m pretty grateful for that, because I *absolutely know* that if the builder didn’t need to do it, he wouldn’t. Amending and backfilling that much soil sucks, and I don’t want to depend on the original builder to get that right (cause I tell ya, they skimped on a whole bunch of other stuff that I’ve been fixing!).

Our industry doesn’t have building codes and as such need to compare what we make with what other people make in order to gauge how good our stuff is. That usually results in purse fights and secret clubs, and rarely does much for us as an industry and I can see why people might shy away from engaging in these conversations.

But to stop asking is to stop learning. Worse yet – to suggest that it’s not even worthwhile is utterly absurd. It drives me nuts when people write posts that suggest that principles and standards of quality are cumbersome (even if they didn’t mean to suggest it – which I don’t think Jeff did – read the comments and you’ll know what I mean):

The bigger and more grandiose the set of rules you come up with, the more severe the danger. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you’ll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules! And, of course, a critical mass of programmers patient enough to read Volumes I – XV of said rules. You’ll also want to set up a few messageboards for these programmers to argue endlessly amongst themselves about the meaning and interpretation of the rules.

Now let’s transpose this sentence a bit, and apply it to an industry that’s just like ours (the building industry, as discussed above), but a whole lot more mature (my replacements in brackets):

The bigger and more grandiose the set of rules you come up with [for building houses], the more severe the danger [of never getting the house built]. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you’ll find yourself believing that every possible situation in [building a house] can be prescribed, if only you could come up with a sufficiently detailed set of [plans]! And, of course, a critical mass of [builders] patient enough to read Volumes I – XV of [the local building code]. You’ll also want to set up a few [city building inspectors] for these [builders] to argue endlessly amongst themselves about [whether the builder built your house properly].

Properly Breaking The Rules
Don’t get me wrong here – I’m not a complete dork espousing that we need to walk in step to a set of software building codes. People break the rules when building houses all the time – but they do it from a perspective of understanding what it is they’re breaking. For example – one of the greatest architects of our time (Frank Lloyd Wright) loved to break rules and even have fun with the concept – even creating things with no right angles at all.

I love breaking the rules. I can feel Steve Harman sweat a little bit when I write code ahead of a test and I’m absolutely sure baby Alt.NET cries a little when I embed a SQL statement in my code (which yes, I just did the other day and I’m damn proud of it – kids dont’ do this at home, I had my reasons). The difference is that I KNOW the reasons why this is bad – and I also know why I did it in the first place. I was able to work through the issues and ultimately decided that breaking some principles would be just fine in my case (and no, I’m not going to tell you what it was that I did – but you’ll dig it when you do see it).

Summary
I don’t like being negative and I feel like that’s what this post is – so let’s see if we can turn that frown upside down if only because I like Jeff a whole lot and I feel like I’ve been picking on him of late (that last post was all in good fun I should point out) – and when my computer blows up I’ll need his help some day :). I do know what Jeff was after with his point and I’ll go so far as to defend him on this – that blindly following rules instead of your skills is actually a detriment. But your skillz gotta be good if you’re going to diss the Gang of Four and Uncle Bob! What Jeff might have wanted to say is:

LEARN THESE RULES FIRST AND USE THEM! Then you can decide if they don’t fit what you’re doing!

The people that made those principles up are quite smart, and have been doing this for a long, long time. Please don’t take Jeff’s post as the 3:00 school bell (where you run out to the parking lot and smoke cloves and drink wine coolers with your emo friends) – you’re *not* excused.

This entry was posted in Philosophy. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

28 Responses to Patterns, Purists, and Sinkholes

  1. taelor says:

    I come from the Ruby camp, and really think that my time spent learning how the Rails and Merb community do things really helps me in my new job using the Microsoft stack,

    There are a lot of principles/codes/standards that you can learn from Ruby, and Rails that will help you no matter what the syntax is.

    BTW, ALT.NET is great, I love what those guys are doing.

  2. Dmitri says:

    Comparing software with building construction is somewhat meaningless – the processes are fundamentally different. These domains do not really map onto one another.

  3. Daniel says:

    Just at having rules is a good idea in general, understanding why they are in place its even more important. Coding styles guidelines can be very useful for maintainability, but can obscure the actual quality of the code.
    Regulations come from a different perspective altogether, they are placed to guarantee safety or conformity. There reasons are not yet relevant to most programming processes and thus cannot be compared.
    regarding breaking the rules.. here is a post on the issue:
    http://design-to-last.com/index.php/Technical/software-design-rules-made-to-be-broken.html

  4. John says:

    Jeff’s goal is to promote a reaction and drive traffic to his site. I won’t visit either of the sites that he is involved with.

    Software is going through the same growth pains that all engineering professions have gone through.

    I’ll bet that when bridges were still wooden that a lot of people would have said “you don’t need to study statics in order to build that bridge, we’ve built other ones just like it nearby and we need to build something there before November when the river freezes. We don’t need theory and standards slowing us down”.

    What about bridge building today? You must have a civil engineering degree to design roadways and you must keep up with industry standards. You might not remember every equation that you learned in statics, but you do know how to figure out how much stress that bridge is going to receive with a full load of cars during rush hour on a windy day.

    In 50 years, you’ll need a software engineering degree to be a serious programmer (i.e. non-drag-drop) and you’ll understand standards, design patterns and best practices.

  5. Jon Kruger says:

    That’s funny, we always joke at work about Steve Harman giving us the beatdown when we don’t write out tests first. :) Sadly I won’t be working with him anymore.

  6. Cole Shelton says:

    There is definitely a balance to be found when creating guidelines and rules for coding, and although I agree with this article to a certain degree, I’ve always disliked comparing construction projects to software projects. The reason why is that software development is more akin to traditional product development than it is to construction or manufacturing projects. Software developers constantly prototype, test, and re-factor their code, does that happen on most construction projects? No, they follow the old waterfall method, which has mostly been abandoned by software development firms (with the exception of certain “critical” systems).

  7. KevDog says:

    Building a house != Building an application. And the sooner people get this the better for our industry. The building industry has a set of practices to allow any idiot to build a load bear wall etc. However, software is so adaptable and flexible that it is almost impossible to define any rule that will work in all places.

    This comment really doesn’t make sense to me. Different construction projects have different rules. Different software projects will have them also. The “impossible to define a rule that will work in all places” is a complete straw man. No one has made that argument that I have seen and Rob surely didn’t.

    I sometimes get the feeling that people who insist that “there are no rules” have never learned the reasons behind what they are denigrating.

  8. Dennis says:

    >>>>Wrong. I’ve been on 2 projects in the last 3 years (outside of Microsoft) where “the management” decided to use Gridviews with Object Data Sources explicitly, and no unit testing because of time. This was driven by *2 people* in the group, and I threw a tantrum.

    While you were throwing a tantrum did the software the other guys wrote solve the problem it was written to solve?

    You do know building codes differ depending on the type of structure and the location. I wonder how the buildings in areas where the codes are less stringent manage to continue to stand. I also wonder how some of the houses in my area that are 100+ years old and built before there were building codes manage to still be standing.

  9. Steve Py says:

    @ble
    >>>Guidelines are created by more experienced(passionate) people to keep inexperienced (and possibly less passionate) people from doing stupid things. This is a good thing.

    Agreed, though I view guidelines as being equally valuable to experienced developers because they promote consistency through the life of the product.

    Every new developer put into a project isn’t going to be a graduate. Arguably the second* biggest contributor to balls of muck that I’ve seen is bringing replacement experienced developers into an existing project that doesn’t have guidelines, or guidelines that were not followed.

    Even Bob has admitted recently to having to choke down his own dogfood on a project. He definately has the skill and experience to do the right thing. It’s not just a question of “skill” or “experience” of developers, it’s restraint. Guildelines should be viewed and encouraged as a way to keep teams in-sync.

    *The largest is a project with no revision control system.

  10. Steve Py says:

    >>>Most projects I’ve worked on *have* building codes. They’re called “coding standards.” Ever read or written any?

    >>> Wrong. These aren’t “building code” – they are what your boss or company think is good, not what the industry standardizes on.

    Wrong, they are a building code. No, my boss/company didn’t write them. We, the development team wrote them. No, they’re not an “industry” standard but frankly I don’t “want” the industry involved in my projects, otherwise I’d work open-source. It is a building code because in the world of the project that I work on, the development team is frankly the only industry that matters.

    >>>Basically if everyone (in the context of a project) agrees to a set of standards & rules, *follow* them

    >>> Wrong. I’ve been on 2 projects in the last 3 years (outside of Microsoft) where “the management” decided to use Gridviews with Object Data Sources explicitly, and no unit testing because of time. This was driven by *2 people* in the group, and I threw a tantrum.

    Congratulations. Though 2 people hopefully isn’t everyone. Next time read/quote the whole statement. My point is not that you have to blindly follow rules (especiallt set down by management), but *when* you break them, it better be based on more than just “I know better”. Other team members should be consulted and the deviation from “best practice” should at minimum be documented as to why you needed to deviate. It’s about having consideration for the rest of the team. If the team accepts a consensus on how the development should be done, you should honour it and make sure it’s understood why and how that may need to be worked around. There ain’t no “I” in team so unless you mean to say you look to the team for consensus before you decide to start getting excited about breaking rules and embedding SQL, etc. maybe consider packing away the 10 gallon hat & stirrups.

    Before this completely goes out of context, a summary:

    Does the industry need a building code? Hell no. But development teams need a set of standards and practices that everyone on the (development) team agrees to follow, and it’s the responsibility of each team member to follow those rules. Developers are free to seek ways to improve on those standards, or bend/break them if they need to, but they discuss it before anything gets checked in. “because *I* know when it’s ok to break the rules” doesn’t cut it.

  11. m4bwav says:

    Yeah, I agree with you, I think Jeff said a lot of things that were popular sounding, but not really that thoughtful.

    I mean to me, it’s about not reinventing the wheel, if someone has some good ideas, then take them, rather than spending a lifetime reinventing them.

  12. ble says:

    The problem is not rules or guidelines, it is people. Jeff and Rob are debating the effect without addressing the cause. Nothing will be resolved this way.

    Guidelines are created by more experienced(passionate) people to keep inexperienced (and possibly less passionate) people from doing stupid things. This is a good thing.

    Some times the people have different priorities than the authors of the guidlines and are content to follow them as rules. This is not an ideal state if they are on your team, but it is certainly better than what they might do without them.

    If you want people to quit interpreting the guidelines as rules… you have to change their priorities.

  13. Rob Conery says:

    >>> The building industry has a set of practices to allow any idiot to build a load bear wall etc

    Umm – yah that’s the point. The “idiot” has to use the right mix of portland and aggregate and pour the correct thickness, as well as use the correct gauge of rebar. We don’t – anyone can create stupid software that shuts my Zune down on New Year’s Eve.

    @Chad Geidel When you pour a concrete foundation is it up to what your dad thinks is a good foundation? Or maybe “the way he’s always done it”? Hardly. I have no idea what your foundation to roof analogy means but thank goodness you’re not working on my house :p.

  14. Craig says:

    Amen brother.

  15. Darren says:

    did you find the rocks sexy? because i have to say i’m a bit intrigued with the intimate curves and fixed-width’ness of consolas.

    er. um. good blog post.

  16. Chad Geidel says:

    I’m with Iain. We really need to get rid of the “Software construction” metaphor. It breaks down in the most simple of cases. My dad owns a concrete construction company and for most of my life (so far) I’ve worked for that company. When you pour a concrete foundation, no amount of “tweaking” will make it a roof later. When you build a wall, you can’t change some dimensions and turn it into a driveway. For that matter the building materials themselves are single-use ONLY. What software has those properties? It’s a nice fairy tale to think about, but it just isn’t like real life.

  17. mob says:

    Why are people like Jeff et al equating good principles and patterns with “rules”? I think they are seriously missing the point by doing this. SOLID and other patterns and practices are *NOT* a set of “rules”. Patterns and principles guide development and can be applied in any number of circumstances and with much “creativity” by the developer while still producing proven and predicitable results. These in no way hem in a developer or make him a mindless code monkey. In fact the opposite is true, they enable a developer to practice his art without being bogged down by the foul odours of rotting code. It’s unbeleivable that there is even debate about this!

  18. Brady says:

    “because I know better” – rofl – sure you do . . . sure you do

  19. Iain says:

    Building a house != Building an application. And the sooner people get this the better for our industry. The building industry has a set of practices to allow any idiot to build a load bear wall etc. However, software is so adaptable and flexible that it is almost impossible to define any rule that will work in all places.

    So the best you can do is a set of guidelines, and as Jeff says if those guidelines become 500 pages long, then they are really not worth anything.

  20. Hadi Hariri says:

    Rob

    If Jeff truly understood what he’s talking about in his post, then he wouldn’t have made that post.

  21. First; great post.

    The part about “learning the rules first and use them” is excellent. After gaining some practical experience in different situations will a context for the rules be better understood. Only with enough experience will one have the knowledge required to bend, or break rules. In doing so, they will likely add/substitute new rules to ensure no basic principles are overlooked.

    Generally rules are like road signs put in place to guide us from a past incident that caused harm. For example a yellow sign on a curve (15 mph) can be exceeded many a time, but a little ice/snow, or a deer around the corner could mean a bad outcome. The more one travel the road and understands surrounding conditions, the faster they can go with minimal increase risk (to a point). Knowing were the point lies require deeper understanding of past experiences.

    Pilots have a similar set of rule they follow when flying referred to as the flight envelope. Basically a box defining some understood boundaries. Depending on aircraft type, weather conditions and pilot experience the size and shape of the box changes. There is a group of pilots who choose to fly outside of the box (perhaps for excitement) and are referred to as Test Pilots. Test pilots generally some combination of above average training, and/or experienced. Pilot lacking qualifications that venture too far outside the box (for their skill level) have another name, statistics.

  22. Rob Conery says:

    >>>Most projects I’ve worked on *have* building codes. They’re called “coding standards.” Ever read or written any?

    Wrong. These aren’t “building code” – they are what your boss or company think is good, not what the industry standardizes on.

    >>>Basically if everyone (in the context of a project) agrees to a set of standards & rules, *follow* them

    Wrong. I’ve been on 2 projects in the last 3 years (outside of Microsoft) where “the management” decided to use Gridviews with Object Data Sources explicitly, and no unit testing because of time. This was driven by *2 people* in the group, and I threw a tantrum.

    In terms of me being a hypocrite – read the post.

  23. Steve says:

    Rob,
    Nice post. Patterns and rules are great for building great software. But some people are too theoretic regardless of different situations. We should be pragmatic for software development..

  24. Steve Py says:

    Touting that we (community) *need* rules, while you take the liberty of breaking said rules when it’s convenient simply because “you know better” is just being hypocritical.

    Most projects I’ve worked on *have* building codes. They’re called “coding standards.” Ever read or written any? They often end up a gospel of rules on best intentions for the well-being of the project, Except after a few months or years into projects it’s as if they were written in sandscrit.

    I generally agree with Uncle Bob; Principles, patterns, methodologies, rules, and the like aren’t the cause of grief in projects, lazy developers are. But in the same light, principles, patterns, methodologies, and rules aren’t the solution to grief in projects, I believe it boils down to “do unto others…”

    Basically if everyone (in the context of a project) agrees to a set of standards & rules, *follow* them. Before you arbitrarily decide to break them, get concensus and break them in a way that others will be able to understand, such as commenting the “why” into the application.

    The road to hell is paved in best intentions. I’m sure more than a few developers that might be held accountable for balls of muck of projects didn’t write things the way they did because they just didn’t know better or care, those little hacks & cracks are just a result of “I know when it’s ok to break the rules.”

  25. Really nice post, Rob. I really liked how you justify the case for learning the rules … that’s the first step on the zen journey for our industry/art.

  26. It’s not enough to say I have rules, and you either follow them or you are a dumb dumb head.

    You have to explain why.

    That’s what your boss did for you that day when he explained the clay.

  27. Rob Conery says:

    ROFL you caught that! Good man!

  28. Chad Myers says:

    It’s a little amusing to me — and the irony not lost — how you make a basically fundamental ALT.NET point in your post while simultaneously insulting it :)

Leave a Reply