The Fall Guy (or Representing Open Source in the Business)

The problem with being the developer who can write at an open source company is that you end up being enlisted into the whole “Please explain how open source works” discussion when the company hires non-technical managers.  You end up as the representative of this strange thing called “open source.” A VP (not yours) calls you up and says, “Hey, could you explain what open source is to our sales team?”

You seize upon this as an opportunity to spread the Gospel of FOSS. You prepare elaborate slides that speak of Cathedrals and Bazaars. You turn some Lessig into an inspirational dramatic monologue that will inspire these non-developers to start thinking of OSS as the heroic effort we are mounting to take back control from proprietary vendors and create an even larger sharing economy. You think that maybe it is appropriate to introduce some of the developers that work on the project that company is currently making money…

…and then you show up at the “Sales Kick-off” meeting and you realize that this is more of a Glengarry Glen Ross joke festival than it is an audience receptive to the idea of profiting from a sharing economy.  You quickly try to revise slides about “Free as in Beer”, because you realize that any mention of beer is going to get this crowd derailed pretty quickly. They scheduled you at the end of the day, after the VP of Sales gave a speech that involved football metaphors and after the regional sales director had a loud fight about territory with the sales team.  You realize that no one really wants to hear about OSS because they are all about to go out on some sales team-building exercise that involves a lot of drinking and more discussion of sports.

You are summoned to present with “…Ok, some hippy developer is going to tell us what this freeware @#$# is all about anyway. Go ahead show ’em how to ‘make it rain.'”

If this is your job, you’ll find yourself in a room full of people asking you questions like “Alright, so do you geeks have anything better to do with your weekend?” and “Why are my customers getting all worked up over open source? I don’t get no commission on this crap.”

Some things that you’ll notice in the reaction:

  • People with a background in business and sales have no idea why you’ve been participating in open source for years.  Not only do they not understand it, some of them discount the entire idea (even if the company was built atop an OSS foundation).
  • Even if you think you’ve explained open source, there’s a large portion of the audience that either wasn’t listening or refuses to admit that it could ever work. (Someone will make a joke about how you are a communist.  It will be unclear whether that person was really joking or not.)
  • Jokes will be made about open source being about “free love,”, “hippies,” and “unicorns.”
  • Invariably, someone from the 1980s will show up and talk about how they once made a lot of money selling business software.  This will be used as an attempt to show others that your generation just has it all wrong.

If just the right kind of manager is there, everything you say about the “possibilities of open source” will be dismissed as over-idealistic nonsense.  Even though you might have just delivered a presentation on how Hadoop has created billions of dollars in value and how organizations like the Apache Software Foundation act as foundries for innovations that drive computing, someone will invariably stand up right after you and say, “Ok, enough about this open source crap, how are we going to make money?”

You realize that your “open-source” stuff is just going to be used as a scapegoat for a sales team that has no idea what OSS is.  This is the reason why you see headlines about large companies canceling support for OSS projects and products.  It isn’t because they couldn’t find a way to “monetize” – no it was often because they refused to understand the gold mine they were sitting on.

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”

Top 10 Phrases at Work: November 19, 2012

This is a list assembled from a scientific poll of 2 million “knowledge workers” conducted via the Information Super Highway.   On November 19, 2012, these were the top 10 phrases uttered in a business setting:

  1. “Is that me or you?”
  2. “Why don’t you try closing some apps?”
  3. “How many people in the office are using Spotify right now, WTF?”
  4. “It isn’t me, I’m on a wired connection.”
  5. “I think it’s you, I just had a great conversation without any of these problems.”
  6. “Maybe we should try Google+?   Are you on Google+?”
  7. “How the hell do I start a Hangout?”
  8. “Do I have to be in this meeting?”
  9. “Can you just call my cell?”
  10. “Ok, my cell signal is very spotty.  Can we move this meeting to email?”
  11. “Do they really want me to fax this to them?”
  12. “Do you know if we even have a Fax machine?”
  13. “Do you have a second, I need someone to show me how to use the Fax machine?”

And, my favorite:

14. “What timezone did you schedule this meeting in?”

Free Books Build an Audience, Just ask the Founder of SAS

From today’s NYTimes article on SAS and the challenges it faces from IBM here is an interesting scene. Goodnight built an audience sending free books. Granted, this was before the advent of electronic booksellers, but I’m fascinated by the idea of Goodnight packing up free book shipments and sending them to potential customers. It is exactly the strategy that today’s technology companies could learn from. Send your audience something free, they will remember you forever.

From the article:

“THE company traces its roots to a time when computing was costly and for the few. Originally called Statistical Analysis System, it was founded in 1976 by Mr. Goodnight and three colleagues from the agricultural statistics department at North Carolina State University. Its techniques were initially used to calculate the intricacies of soil, weather, seed varieties and other factors to improve crop yields.”

To build an audience, Mr. Goodnight spent nights packing up boxes of computer tapes and manuals, which he sent to university and corporate researchers. Soon, companies wanted him and his academic colleagues to develop software tools tailored for industry. In 1976 at a users’ conference, 300 or so people showed up, many from business.”