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.

Recently at my gig we converted a large project from HG to Git. There are a lot of developers on this project; many who have never worked on Git so I expected a few bumps. So far it’s actually been pretty smooth sailing but yesterday I was contacted by a dev with a Git problem I had never seen.

The day before he had made a commit and pushed it to the server but now the content of the commit was gone. Not reverted mind you, just gone, like it had never happened even though the commit was clearly still in history.

To be clear, looking at the history of the entire repo showed the commit and it’s changes as something that happened. But looking at any of the individual files in the commits didn’t show the commit at all. WTF?!

This turned out to be the result of a bad merge by another developer. I was able to recreate the scenario, take a look at the weird history:

ryber$ git log --graph --oneline --all
*   1b4cd92 Bad merge by dev B
|\  
| * e879eb6 This is the missing commit by dev A
* | 93933b9 commit by dev B
|/  
* 6baed99 root commit

Here we can see that e879eb6 is in history. You can see that part of that commit was a change to foo:

ryber$ git whatchanged e879eb6
commit e879eb6007ddef2a955a71651bcf31a25727b510
Author: ryber
Date:   Sat Mar 22 16:37:28 2014 -0500

    This is the missing commit by dev A

:100644 100644 eb314de... e3525a0... M  baz
:100644 100644 ae3cab0... cf561bd... M  foo

Yet, if we look at the history of foo that e879eb6 is missing!

ryber$ git log --pretty=oneline --abbrev-commit -- foo
6baed99 root commit

What happened here? Where did e879eb6 go in the history of foo? I can understand if the change was reverted but shouldn't we see some history of that revert? This is where we get into the bad merge

You may have notice that the missing commit includes another change to the “baz” file. It turns out that the second dev also changed baz in 93933b9 and was forced to go into a merge conflict when he pulled. To someone new to git the merge process might be a bit shocking. This is because you see all of the changes impacted by the merge. This includes your own changes as well as all of the changes to files in the tree you are merging in that happened after your last common ancestor. Developer B was presented with something like this when he was merging:

ryber$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
  (use "git pull" to merge the remote branch into yours)

You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

	modified:   foo

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:      baz

You might think “What the hell? I didn’t change foo?! Why is foo here?”. You might even attempt to get rid of the foo changes … which is exactly what happened. It’s actually kind of hard to do from the shell but fairly easy to do from some gui tools like SourceTree. From the shell you just have to issue a checkout of a previous version like this:

ryber$ git checkout HEAD^ -- foo

Then an add, and a commit and voilà! The file has now been reverted to it’s previous state as part of a merge and it’s individual content history no longer contains the missing commit.

You may be wondering how we got out of this mess? We simply cherry-picked the commits back into the head. Not very subtle but it worked.

ryber$ git cherry-pick e879eb6

A short list of my favorite coding music:

Information Society

In the late 80’s and early 90’s as I was getting into hacker culture InSoc was a major influence for me and my friends. They have everything: songs inspired by William Gibson’s cyberpunk novels, love songs to Nikola Tesla and IBM, samples from Star Trek, and a sound that gave the impression it was made on an Amega at 3:00 am after they left a rave. Best of all they regularly encoded messages and hacker challenges into analog data-sound tracks at the end of their albums. The minute a band has you wiring your CD player into an old handset modem they’ve won.

Kraftwerk: The Mix

It may be cliche for a programmer to love Kraftwerk, but I don’t care. More than just a best-of “The Mix” is rare in the world of electronic re-mix albums in that it’s mostly better than the originals. I particularly find the version of “Computer Love” to be the best out there.

Robyn: Body Talk

Don’t chalk up Robyn as just another disposable dance club act. The electronic music she produces is impeccably produced and well crafted. It has numerous interesting patterns and layers that pay back on repeated plays. The Body Talk series is by far the best. For something even more abstract check out her work with Röyksopp.

Santigold

Whenever I listen to Santigold I imagine this is the music the the rastafarian hackers from space station Zion are listening to in Neuromancer.

The Soundtrack to Conan the Barbarian

The soundtrack was made first, and then the movie was basically a giant music video for a remix of Carmina Burana. Perfect background music for epic coding.

A few others

• Gary Numan
• The KLF aka The Justified Ancients of Mu Mu aka The Timelords
• The Orb
• Aphex Twin
• Brian Eno
• Daivd Bowie’s Berlin trilogy (Low, Heroes, Lodger)