Break Through Server-side Bias and Surrender to Javascript

You have a server-side bias and you don’t even realize it.  I know this, and you need to know this.  It’s keeping you back a bit. Step one is to admit that you have a problem and that your addiction to easy server-side frameworks is ruining your performance.  You’ve used frameworks like Rails, Django, WordPress, or one of several hundred Java web application frameworks for years and you are resisting this move toward Javascript.  Yes, you’ve “embraced” Javascript throughout your applications, but you might be missing the larger point – Javascript isn’t here to make your server-side applications more “reactive”, it isn’t just a nice feature to add to a larger application.

That Javascript you keep on insisting to serve from your server-side framework…that is the application.  It’s taking over.    Your server-side framework won’t be doing anything resembling templating in a few years because that’s the job of the browser.  Yes, yes, you might have a few “high value” pages or pages that have to be hosted on a server because of security constraints, but if your web site requires a round-trip to a server to render a web page… well that’s old people thinking.

The “geographical center” of your application is no longer on the server-side.  You shouldn’t start your application thinking about what server-side framework it is going to be based on, because it won’t be based on a server-side framework.   In fact, you may use many, but they will only serve to support what will essentially be a client-side Javascript application.

I understand how you feel, you might read this and think – “No, we’re not moving everything to client-side Javascript frameworks, no.”  The willful ignorance you are embracing here is a defense mechanism.  As a Java developer in the middle of the last decade.  I saw the next generation using PHP and Ruby and I tried to explain it away for a few years as just a passing fad.  It wasn’t, and I still see a lot of developers in my age group reflexively resisting dynamic languages.  Resisting change is a mistake – you’ll be obsolete before you can say, “Wait I didn’t realize that the browser could do…”

With the rise of ReactJS, AngularJS, Backbone, and a number of other good client-side Javascript frameworks I’m seeing a new kind of bias – server-side bias.  There are people out there who, for whatever reason, be it ignorance or otherwise – these people fail to realize that the days of having some dynamic templating engine on the server-side merge your data with some HTML… those days are coming to a swift conclusion.   It was fun while it lasted, but this “mail-merge” approach to retrieving a row from a database, packaging it up in some object, and then “merging” it into a template.  The view layer of this is moving client-side, quickly.

And, it’s moving to the client because it’s an order of magnitude faster to serve what is essentially a static AngularJS application from a CDN than it is to muck around with serving the same from some server-farm (even with the help of memcache).  That’s the thing, once you start doing this you realize that you only really need a server-side framework for API calls.  That’s really it.  All your server-side frameworks are doing in five years time? JSON, and maybe futzing around with a few databases.

Don’t get me wrong, there will be people writing Rails RHTML and Java JSPs for many years to come much in the same way that COBOL developers still run systems packed away in government data centers.    But, Ruby and Java developers that fail to embrace this client-side Javascript trend will find themselves confined to internal applications – the Oracle Forms of 2020 is Ruby on Rails.

The 7 Rules of Software Development

Nuremberg_chronicles_f_180v_1I hate simplistic blogs like “The 10 Rules of XYZ”, but who am I to buck the trend?  Why the picture?  Every time I read one of these simple lists of edicts it strikes as being very “papal”.  Here I’ve simmered down development into 7 rules:

1. There is No Such Thing as Architecture, and you should avoid “Architects”

Good software developers work in small teams, they discuss everything, and the really good ones understand that “architecture” doesn’t really mean much.  Yes there are choices about what software “stack” you are going to use and how components of the system interact, but it is a fools errand to view “architecture” as something separate from development.  Software is built up piece-by-piece, and you make a thousand little decisions here and there, all of which end up in a final structure.  Developers can discuss “an architecture”, but it is just an abstraction, it doesn’t really “exist” outside of the system as it has been implemented, and it is more ceremony than anything else.

The problem with the whole idea is that it suggests an analogy to construction, you know “real” architecture. We’re not in the business of standing up houses and/or buildings, but, invariably, every time someone tries to create an architecture they end up drawing models that almost never line up with reality. Let’s retire the word “architect” as it applies to software development I’m not saying that there can’t be a plan, or a loose collection of rules, but it is the really bad developers that get stuck on this idea that there is “an architect” who is telling “developers” what to do.  (That’s the worst kind of place to work.)

That’s not how it works.  You can make it work like this, but, trust me, your software will suck as a result and you won’t be able to grow a committed team.  Why? Because of the next rule…

2. Everybody Grows

Why is there no architect?  A couple reasons. First, every real software architect I’ve come into contact with is a train wreck. They used to be a developer and they were either so incompetent they had to be promoted out development or they were the kind of individual that thought so highly of themselves they fell naturally into the role of dictating design decisions. Second, having someone be “the architect” gives everyone else a good excuse – something to blame when a system falls on its face. When you have an “architect” you’ll usually see disengaged teams, teams that don’t want to stay late because they are excited about the work they are doing, and a corporate culture ruled by political dysfunction.  Think of a room full of disaffected developers saying things like “Well, it wasn’t my decision to do it that way?” and “Well, I don’t know why we did that, go ask the architect.”

The working alternative is that everyone on the team makes a contribution, and everyone on the team is responsible for at least some portion of the architecture (which, remember, is a useless abstraction). The rule is that decisions are made by the people doing the work, and you should rarely override these decisions. This is essential for long-term success. If you force a strict hierarchy on to your development team, you’ll never give anyone the opportunity to grow. What you need is a self-aligning hierarchy (or as close to self-aligning as possible… people still need bosses, don’t get me wrong.)

3. Avoid Developers who think there is an Objective “Right”, There is only “Satisfies Current Requirement”

This is not to say that I believe in a sort of software relativity in which no solution is better than another.  I do believe that there are good ideas and bad ideas, but if anyone on your team decides that they are the arbiter of Right and Wrong you need to have a long conversation about how a team works. You need to remind them that there is no “architect” and that there are really just people responsible for different components of the system. Now, a little disagree is alright, but in my travels throughout developerland I see a lot of developers running around with this idea that they’ve discovered the One True Way. They haven’t, and there isn’t one.

(Note: there’s an exception to this rule: Subject matter experts – real subject matter experts.  For example, if you are in a meeting with someone who, say, wrote a book about Tomcat, and you say something about Tomcat that causes that person to object.  Listen.)

If disputes seem unresolvable, you should absolutely intervene and nudge a decision along.  This is what management is for, but if you have people on your team constantly debating software development dogma, you should stop them.  Yes, there’s a right way to do File I/O.  Yes, there’s a right way to use a UITableViewController in iOS, and, yes, there’s a correct way to configure Tomcat. No, there isn’t one right way to implement an API, there are several hundred, and you have to give team members enough room to screw up.

4. One Metric for Success == The Number of Times you’ve screwed up

If you are writing software worth writing then you are likely doing something that’s never been done before.  (If this isn’t the case, you are likely writing software that shouldn’t be written but that’s a whole different post.)   If you are forging new ground, there’s a good chance that you are going to screw up… frequently. Good software development teams talk about failures in a way that doesn’t ostracize the people responsible. You want a team that can joke about how they made a bad decision.  You want a team that isn’t constantly trying to look invincible to management.  Everybody screws up.

I’m not telling you to reward your worst programmer a special nerf gun because he’s constantly screwing up production, you shouldn’t “celebrate” screwing up, but you should set the tone that mistakes are valuable. Read some Petroski, he’s written good books on engineering failure (if I weren’t such a lazy bastard I’d link to them).   Long story short: if you don’t want to read his books is: failure is engineering progress.

5. “Is it done?” is to be met with Laughter.  There is no “Done” there is only “Satisfies Current Requirement”

I’ve worked on software long enough to realize that there is no “done”. Stop saying that word, it’s crazy. No matter how much you may want to forget about that code you wrote seven years ago, there’s no escaping it. Software is never done, and it will always break. There will always be something left to do.  If your management team is saying things like, “I thought we were done with that?” or “We don’t have to worry about that system it was done years ago?”  It is your job to remind them that software development is an endless pit of risk – an inescapable gravity well of budget allocation.

The two acceptable responses to “Is it done yet?” are “Software is never done” or “Welcome to the Jungle, we’ve got fun and games.”

6. Don’t Believe Anything You Read Online About Development (Avoid Dogmatic Process)

This is the most important rule of all.  Don’t find some easy software development dogma or list of rules and follow them… that includes this blog post. You should be very suspicious of any online manifesto that talks about ideal software development practices or anyone who takes time out of his weekend to write a blog post entitled “The 6 Rules of Software Development”. Please think for yourself.

One of the worst development teams I ever worked on was a team that was heavily influenced by a popular agile consulting firm that will remain nameless. First of all, the software being produced was awful, but I’m not sure that had much to do with the team as much as it had to do with the company that ran the project. There were architects, there was a guy running around telling everyone he knew what was right and wrong, the place adhered to dogma so much so that people quit over it. Including me.

If someone comes to you totally energized about some “Agile manifesto” they just read, or if they start preaching TDD as the One True Way.  Take them aside, let the know that the workplace is no place for religious proselytizing. While there are many good ideas in the software process community there are also many ideas designed to sell books and consulting services.  Every project and every team needs a slightly different process.  There is no cut and dried model for software development because there is endless variation in humanity.

7. When Everything in this Post is a Lie, It’s Time to Move On

Eventually, as the project matures you’ll experience a slow shift to maintenance mode.  “Management” will start focusing on “risk” and asking questions like, “Who is the architect of this system?” or “What is the Total Cost of Ownership for ActiveMQ?”  At this point, every single rule in this list will experience a rapid inversion point.  There will be an architect, there will be strict definitions of senior and junior developers, someone will start telling everyone else they know the One True Way, programmers will be fired for making even slightly wrong design decisions, you’ll start having status meetings that talk about “finishing” the project, and someone will show up with a bunch of cultish books on process and convince management send everyone to an Agile re-education retreat.

Fire Your Designer and Choose One: Bootstrap or Foundation (…unless you really are that good, and that isn’t likely)

Every time someone brings up Twitter’s Bootstrap or the Foundation library by Zurb there is always bound to be a food fight over how using CSS and Javascript libraries “dilute a web site’s brand”.   I’m writing this post because I’d like to encourage an even larger, more vicious food fight.  Not only do I think that you should use Bootstrap or Foundation, I think you should fire your designer.  You don’t need them anymore (unless they also know how to program, which they probably don’t).

Designers tend to hate Bootstrap…

…and I understand this.   I understand this because graphic designers are Artists who believe that a site’s “design” emerges from the organic values it represents coupled with the refined sensibility that only they have achieved through years of experience and education.  Do the core values of your brand suggest the rounded corners and subtleties of Bauhaus or Art Deco?   Or does the internal tension of your product’s subtext call for buttons that resemble primitivist surreality?   Your web site is more than just a static entity it needs to be a “bold statement.”

Right?  Because web site design is Great Art.

…and then I just install Bootstrap and the designer flips out.

Using Bootstrap is like “serving McDonald’s at a fine restaurant” – people don’t love a brand because it looks like all other brands, they love a brand because it provides a unique experience and style.   The look and feel of every element is as important as the functionality of a site.  Or that’s what the response is.    The designer then proceeds to tell the client that “Bootstrap dilutes the brand… the most valuable asset you have…”

…and while I understand this, I also believe that this response is complete bull$#%# (unless you are really, really good, and most designers aren’t).   To me this boils down to risk, money, and time.

  • Unless you have Rune Madsen or Edward Tufte on your team, there’s a risk that you are going to end up with awful custom CSS.    (If you are this good, then go for it, this post doesn’t apply to you.)
  • It’ll cost you an arm and a leg to reinvent the wheel, you will literally be paying for someone to reinvent the button.
  • Instead of focusing on requirements and functionality, you will be wasting your time on visual minutiae.

“Use Bootstrap or Foundation: I Don’t Care Which One”

Let’s take Bootstrap as an example.   I view Bootstrap the same way a Java programmer would view the java.util package or a Ruby programmer would view the Array class.   It is a guaranteed baseline of functionality – I know what is in there, I can easily make use of a standard interface, and, if a designer really needs to, they could go and customize it however they wish.  If a Java programmer on my project came to me and told me they were going to reimplement the HashMap class because they had a better idea, I’d quickly look for a replacement.  No, full stop.  Don’t reinvent the wheel.

If a project needs a web site, I gather requirements and start to implement a prototype using some standard libraries:  Bootstrap or Foundation, jQuery… the usual suspects.  I will select these libraries because they support a set of standard requirements I know I’m going to have to satisfy,…

…but I’m not asking permission to use these features.  

I’m not going to stop and engage in a dialog with a designer about whether the site should use a navbar or pagination… I’m not going to stop and consult “the designer” and ask them how the form should work or whether the site is going to use color coded labels to convey importance (I may ask them what color the labels should be… maybe).

The “Web” is beyond this stage.   It used to be “Art”, but in 2012 we’ve all agreed on a basic set of visual cues… haven’t we?   Every site worth using has converged on a set of standards, just like every iOS application or Android application provides a set of common design elements.

“Don’t tell me that, in addition to creating a web site to deliver online training for Chiropractors that we’re also going to take a few weeks to reimplement standard libraries for multi-select buttons.”

Is that what the Designer Wanted?

Then it happens.  Then the designer somehow convinces the client that, like Apple, they need to give the designer total control over the look and feel of the web site.   Because, you know, Jony Ive is the real reason behind the success of Apple’s products.  They appeal to the CEOs yearning to be Steve Jobs and tell them that Jobs made a bold bet on designers that ultimately paid off in spades.

You’ll be moving along at a fast pace when your client will interject: “that menu looks nice, but have you asked the designer what they think yet… you should really let them own the look and feel of those buttons”.    That’s when you try to explain that these are standards…

You, “These are the same buttons that Twitter uses, that Square uses.”

Designer, “That’s the problem, we’re diluting our brand.”

You, “Bullshit.   You can add a customization layer atop Bootstrap.”

Designer, “That’s not the point.  The point is that the overall look and feel of the site will look like Twitter.”

You, “Have you used WordPress or Google or Chase… you know all these sites have navigation elements and dropdown menus that look strikingly similar.  Are you saying you don’t want…”

Designer, “None of those sites use Bootstrap, they have a custom…”

You, “You can add a layer of CSS to customize Bootstrap, don’t you…”

Designer, “We’re already developed these components in house.”

You, “Your argument for not using Bootstrap is that you’ve already implemented it internally.”

And, the client often buys this line of argument less based on the merits of the argument, and more because the “business stakeholder” feels less threatened by artistry than he is by technology.

What you do as a developer is a mystery, but what the designer does is very accessible.

The Disconnect: Web Design is No Longer “Art”

This is often what it all boils down to – a disconnect.  Designers see frameworks like Bootstrap and Foundation as encroaching on their turf.    I compare it to a Java programmer who avoids ever using Maven or Gradle because they really want to “own the build” and “understand the build from the ground up”.    Except it is a bit worse for graphic designers.

Most developers (or more accurately, most good developers) would agree that reuse is generally a good thing.  If we all ran around reinventing things like LinkedList classes or Dictionary objects we’d get nothing done.    Not only would we get nothing done, but nothing would be portable.  Artists and designers, on the other hand, they often believe that writing CSS and HTML from scratch is just another part of the creative process – this starts to get really fun when designers start to view Javascript as their responsibility.

When it gets to this point, I usually just stop and give the client some simple advice: “Fire the Designer and Choose One: Bootstrap or Foundation”