I had the honor of appearing on ‘Software Engineering Daily’ podcast to talk about practices at John Deere. Topics of discussion include autonomous vehicles, team autonomy and devops overload
This is probably my favorite talk I’ve ever done. The video is from DevOpsDays - Des Moines
Here is the deck from my Agile 2018 presentation on Aesthetic Criticism for software teams:
Here is the deck from my Agile 2018 presentation on Monoliths vs Microservices:
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:
- Start with 1 point
- 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.
- 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:
1 2 3
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.
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.
I should note that most modern languages are moving away from 0 for octal. C#, Python 3, ECMAScript 5, etc. Alas, it is probably too late for Java as changing it might break the .0000001% of programs that did it on purpose.