In the weeks since the google manifesto I’ve been thinking about what I see as a fundamental misunderstanding the nature of software development I wanted to get it off my chest.

Is Programming Math and Engineering?

Yes! Of course it is. Where the author fails is in narrowly defining math and engineering to traditionally male dominated professions. Historically and across cultures women have dominated domestic crafts. Weaving, knitting, embroidery, tailoring, basket and pottery making are all forms of “thing thinking” that require high-level problem solving, mathematics and a deep understanding of materials. Yet we do not value them at the same level of men’s work. This is partially due to the more temporal and replaceable nature of these crafts but it’s also because we do not value women at the same level we value men. So we call the things men do “engineering” and the work women do “crafts”. The fact that men’s traditional crafts involve stone and metal, and women’s involve clay and yarn is irrelevant to the skills needed or women’s interest in them. Just ask Hobby Lobby.

Is Programming Human Language?

Yes! Of course it is. When we program we have several different audiences. The compiler or runtime is one. Other developers that must read and understand our program is another. Some of the worst code I’ve ever worked on was written by coders with poor communication skills. Naming things is hard, composing code into a readable flow is hard. By applying basic composition skills to our code we can help those that come after us.

Larry Wall, the creator of the massively influential Perl programming language has spoken and written extensively on the connection between human linguistics and programming. Perl itself was informed and designed with linguistic principles.

Is Programming Applied Sociology?

Yes! Of course it is. As all programmers who have been around a while will tell you. Writing the right code is much harder than writing the code right. Programmers must be part of the process of gathering requirements and empathising with customers. We have to work hard to ask the right questions, give meaningful critiques, and understand the problems that need to be solved.

Is Programming STEM?

Maybe? My personal feeling is that part of the problem of getting women and men who do not conform to stereotypical “Big Bang Theory” nerdom is in the public perception and marketing of the career. We are working against a harmful and counterproductive vision of the coder as a socially awkward genius sitting in a dark room. Most programming isn’t writing router software or physics engines. Developing software for humans requires a high degree of general purpose problem solving, teamwork and empathy. Many of the best programmers I’ve worked with did not come into programming through traditional educational paths and I’m not convinced that grouping programming with math and engineering is beneficial to it from a marketing perspective. Perhaps it should be in business, design, or even on it’s own.

We are also working against a toxic and misogynistic culture that drives the women who do want to engage out. The most baffling thing about the manifesto is it’s choice to basically ignore the voices of women who will tell you why they left. It’s not a mystery we need brain scans to find out. Just ask.

Velocity is a largely meaningless “measurement”. It’s relative, it’s based on estimation (which we are all horrible at), and it’s subject to all kinds of external forces that impact teams.

A much better thing to measure are the forces hampering our teams from delivering. I like to think of this as viscosity. In science, viscosity is a measurement for how fluid a liquid is. Water flows faster and easier than honey. Similarly, our teams will go as fast as they are capable of. The real issue is finding what is slowing them down.

I came up with an entirely unscientific method for calculating a team’s viscosity. In the course of a team delivering something to their customer:

1. Start with 1 point
2. Add 1 Point for each external team or person (not on the team) you are dependent on in order to deliver. This could be DBA’s architects, operations, security, marketing, etc etc. It could also be another team responsible for some other part of a feature. Maybe your teams are split between “back end” and “UI” for example.
3. Add 1 Point for each required technology needed that your team is not proficient in.

Easy huh? Your goal is a value of 1. Obviously not all values of 1 are equal but it should give you a target to work on. You are free to play with the point system. Maybe dependencies outside of your company or area cost more?

Teams that are self sufficient are going to be faster or at least be more responsible for their own speed. What would it take to get a team with all of the skills and people needed to deliver?

Of course teams impact other teams. Viscosity is all about how a liquid moves in relation to itself. What’s really fun is to take all of the viscosity points for an organization and cross them together. So rather than just run the points of each team, inherit the points from your dependencies. So if your team is dependent on a team with a viscosity of 5 then you now also have 5 as well (plus whatever else).

Map this out and you will start to see the big bottlenecks of your organization. You could create a nice dependency graph and watch as it explodes. Teams that should be really fast suddenly look slow because of a web of other slow teams (usually built to “support” them).

Here is the deck from my Agile 2015 presentation on Architects:

At my current gig we have a fairly large Java web application. It has a Fitnesse suite of around 2000 tests that until recently took about 12-13 minutes to run on a good machine.

One of our developers (@briandanenhauer) felt the there was something wrong with that time and used one of our hackathons to do something about it. He ran the tests under a profiler and found a significant problem with the way we (and Fitnesse) were wiring in fixtures.

Fitnesse has a Import fixture which can be used to import the java packages containing your fixtures. For example:

|Import|
|info.fitnesse.fixturegallery|
|info.fitnesse.anotherPackage|

Our project had attempted to package our fixtures into feature specific packages. Over time this had left us with over 50 fixture sub-packages.

Whenever Fitnesse needed to find a fixture it would loop over the list of imports and look in each package for the fixture. If it didn’t find it it would throw an exception up and then continue looking until it found it. This was resulting in literally millions of exceptions being thrown throughout the run of the main suite.

@briandanenhauer did the simple thing and flattened all of our fixtures into one package and one corresponding row in the import fixture.

The the result was dramatic. A full build of our system went from 13-14 minutes to 6-7! The team was floored and there was much rejoycing! I did a very quick and dirty calculation on the savings in dev time and came up with $200,000 per year for our staff. That would be if every developer ran verify only once per workday (and we know it’s more). That’s a powerful argument for hackathons or just letting your developers have time to make their projects better.

Last week at O'Reilly’s Software Architecture Conference Glenn Vanderburg from LivingSocial referenced (anonymously) something I tweeted a few months back about software engineering. It’s a very good presentation and I think Glenn makes a very strong argument that programming is engineering. Go ahead and watch it. My tweet comes in early around 1:07

I can remember when I made that tweet and I was thinking less about if programming itself was engineering and more about if programmers were engineers. My father was an architect who designed prisons, schools and shopping malls (ok, all prisons). My father-in-law is a mechanical engineer who worked for the US Army Corps of Engineers on top secret projects like the stealth bomber. So I am loath to call myself an architect or an engineer in their presence.

As my father once said when I told him I was considering taking a job as a software architect: “pssh, you’re not an architect until you prove to the state that your work isn’t going to kill someone”

That’s an important point. Architects and engineers (at least structural, mechanical and civil) are required to go through a rigorous education, licensing and accreditation systems. They are legally liable for their work and they are keenly aware that they have the public’s lives in their hands.

In software development you can take a 3 week Node.js bootcamp from a 22 year old and get a job writing financial systems.

If programming is engineering. How do we get programmers to act like engineers (i.e. professionals)?

There is an almost unlimited demand for programmers that need to write everything from missile guidance systems to cheap Candy Crush knock-offs and we seem to have almost no control at all over how these developers are educated. The universities don't teach the art of programming. Most employers don't either. I love the craftsman movement but so far it only exists in it's own little alternate reality bubble.

It occurred to me while watching Glenn that the attitude I (and many others) have had of deriding programming as engineering serves to feed into the idea that writing crap software is ok. Perhaps if we reorient a little towards calling our practice engineering it would help foster the professionalism many of us long for.

Last week I posted a fun little troll of Java on the Twitters and it kind of blew up.

Everyone enjoys trolling JavaScript for it's weirdness but everyone has something. Here's Java pic.twitter.com/SszNlbefLP

— Ryan Bergman (@ryber) February 17, 2015

What I got in response (besides the retweets and favs) was a lot of people who felt the need to inform me of why each line was the way it was (and in some cases how stupid I was for not knowing it). I started to experience a phenomenon that is quite common amongst software developers that I like to call “Wonderland Syndrome”.

“But I don’t want to go among mad people," Alice remarked.
"Oh, you can’t help that," said the Cat: "we’re all mad here. I’m mad. You’re mad."
"How do you know I’m mad?" said Alice.
"You must be," said the Cat, "or you wouldn’t have come here.”
― Lewis Carroll, Alice in Wonderland

Apart from Alice and the Cheshire Cat nobody in Wonderland knew that they were mad. This attitude, to simply accept the rules a system has given to you whether they are logical and good or not is actually a strength in computer programming. In a paper from Middlesex University it was found that successful CS majors were better able to accept and understand the sometimes odd rules of computers.

“To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion”

It's also why we all love puns so much. The problem comes when this understanding moves into an orthodoxy around how it should be. None of the examples in the tweet show this more than the response to the last item. Some people seemed incensed that I apparently didn’t understand that prefixing a number with 0 indicated an octal number and that this is how it was in C and many other languages. "0 is the standard!"

0 is a horrible thing to use to indicate octal. My 3rd grader can tell you that leading zeros are not significant and so 022 - 2 = 20. Why must we surprise everyone with something different? Maybe 43 years ago when C was being created on PDP-8s with 12 bit words it was the only thing to do. I tend to think that even then anything else would have been better.

Fast forward to 1995 and Java had no reason at all to continue with it. I believe they did so simply because of Wonderland Syndrome. "Of course octals start with 0, and hedgehogs make perfect croquet balls."

Yet here we are, running caucus-races to get dry and fixing bugs because of the limitations of a 43 year old computer. THAT my friends, is the WTF.

A couple of months ago Uncle Bob Matrin wrote about microservices as jars (or gems or dlls etc). I’ve been harboring the same idea for a while so I was encouraged to see him talking about it. I’ve also seen both positive and downright hostile responses to him. I’ve been honing in on a way to do this and I think I see where the hostility comes from.

You see there are two rules about microservices. 1) They need to be isolated and 2) They need to be more isolated than that. In fact they need to be Kim Jong-un isolated. When you run a microservice as it’s own deployable behind it’s own REST interface then it’s easy. You can use whatever libraries, languages, even operating systems you want. However, when deploying a jar inside of another application you are suddenly no longer free. The runtime will demand only one version of your orgs favorite MVC for example, and everyone better be on the same page.

So when crafting a jar you need to be dependent on as little as possible. I personally find freedom from frameworks liberating. Besides it’s a “MICRO” service, you don’t need an IOC framework or an ORM at all. In practice I can see many organizations having problems with this, Green developers like glueing frameworks together. Things like Spring make it look like it would be easy to just add yet another jar into the component scan. You need to stop! Because that leads to the dark side….dependency, coupling, and weeks spent upgrading 20 jars at once to Spring 4.1.X when just one of them needs to go.

I know Uncle Bob knows all this already. I’m not sure he emphasized it enough or appreciates how many people will attempt to implement his idea in completely wrong ways.

But I’m going to do it anyway.

I've been upgrading frameworks in a number of projects lately and I felt the need to rant about frameworks I really dislike.

HAML

Several years ago some hipster programmers were frustrated by HTML. Since dogs and babies were qualified to write HTML they weren't able to let everyone else know how awesome they were on 100% of a project. So they invented HAML to protect their smartypants status.

The main battle cry of HAML seems to be that you can write HTML “faster”. As if writing HTML was the bottleneck of programming. If your main bottleneck is writing HTML then either you are the the most awesome programmer on the face of the planet and you need to quit writing web sites and start finding a cure for ebola or you don’t work on anything remotely difficult (lucky you). Thankfully every text editor on earth autocompletes HTML. Which means HAML is a problem disguised as a solution to a problem that doesn’t exist.

(note that I don’t feel the same about SAAS or LESS which at least help to fix some of the major problems with the W3C’s biggest failure: CSS)

ORM's

Hibernate, Rails, iBatis, whatever. ORMs do two things: 1) Save you from writing a bunch of mundane crap early in a project and 2) Guarantee you will spend oodles of time trying to debug a labyrinthian hellhole later in the project. This is the root of what I like to call the the "Law Of Frameworks" which states

Any framework designed to keep you from
thinking about a thing will force you to
have to think about that thing in more
difficult ways than if you had not used it.

I've seen team after team, project after project waste weeks to months fighting ORM's. Stop the madness!

YAML

See HAML. Use JSON.

Apache HttpClient (any version)

Try to think of the most convoluted and stupid way to make a web request. Then make it dumber than that and require at least eight classes to do it. This is HttpClient. This is why people hate Java.

AOP

There is nothing worse than a method suddenly working differently in your production code than it does in tests. This is what AOP does. Making it the antithesis of the Principle of least astonishment. ORM’s often make use of AOP which should be a sign. As does the last item.

Spring

Spring is the most cargo-culted software framework in the world. Almost nobody understands the entire thing. At best people learn a small bit for a little while. Then they leave it alone for 6 months and forget. The framework itself it a giant magical mudball that configures itself with annotations and XML (yes I know about the Java configs but those are not 100%, nor are they really much better). Almost nothing is obvious or simple. StackOverflow is littered with questions about completely obscure, unhelpful, and downright weird errors. The answers (if they have one) are often something along the lines of “oh you forgot to implement and register the AbstractSingletonProxyFactoryBean: (which is a convenient proxy factory bean superclass for proxy factory beans that create only singletons of course). The answer almost never explains what the hell any of this means. Just worship the coke bottle correctly and the bean will show up with candy on the spring equinox!

If ever you choose to upgrade Spring you will find that half the classes you used before have been replaced by other classes that don’t do the same things.

This is the other reason people hate Java.

Here is the deck from my Agile 2014 presentation. If you would like to see it live I'll be presenting it again at dsmAgile

The other night I gave a presentation on real options and technical debt to the Agile Iowa group. We had a great conversation about it afterwards. I was asked to post the deck so here it is.