Then I go talk to the people.
It turns out that builds are performed by the “build master” checks the code out of version control, going into Visual Studio, loading the project, pressing Ctrl+Shift+B, getting an executable, and copying it over to production. There are several different projects and some teams can deploy a few times a week.
As for BDD, some of the lead testers create “given when then” acceptance criteria that are sent to a developing nation for testing. There is no evidence of collaboration, no shared understanding. When the “specs” fail, we still have a silly argument about what the software should do, what the “given when then” means and if it is correct.
When I ask to see the tests running, I am told that the technical staff cannot show me a test run. The offshore testers run them overnight. No one at the corporate headquarters knows how to run them.
This is an example of “Name it, Claim it”, which is far too popular in Software Delivery Today.
I have spent a large part of my career in software working either at established companies on new projects that haven’t made their first customer yet, or early stage startups. They usually have a fun, carefree feel. We spend time exploring the latest technologies and implementing those with the latest in development techniques. The schedules are lax, if there are schedules at all. It is easy to fall into that sort of groove when you don’t have any customers yet.
But, oh how things change when that first big customer signs on. Sales makes deals with customers for things that don’e exist, and then then the crunch starts.
My family and I moved into a new house about a month ago. Buying houses, selling houses, and moving are all terrible. I don’t recommend it. Especially 4 months after having a new child. About a week after we were moved in, sales people started coming by. This is whatever you would call the in-person version of a cold call. No warning, just a random person showing up on my doorstep, usually around dinner time, to hock their wares. They were selling security systems in this case.
Each salesperson used an identical tactic and it reminded me of everything I dislike about sales people, and filled me with a touch of self-loathing for having to sell.
At one or time or another in most technical careers, we get, well .. a chance. Due to a re-org, a firing or a maybe getting a new job, the technical staff is finally free from ignorant middle management. So we make our plans.
The next generation product is going to be good. Really good.
They want to know when it’s going to be done and how much it will cost. Fuh. Not our problem.
Two months later, the company has a new manager, even more ignorant than the one before. This one promises the work will be done before we even know what we are building!
… What just happened?
The body of the paper was shorter than the title.
The title of the paper was “On the Optimization of physically distributed analysis, design, code, test, operations, and management resources.”
The body of the paper two words:
At the time, the best advice of the software literature said that communication costs were expensive. That made the handoff between roles expensive, and mis-understandings and “backwash” when problems escape to the next role much more expensive. Recognizing that, we hoped to improve delivery by “getting it right”, so defects could not escape to the step to follow. For example, we talked about creating a specification that was the 3 C’s and U: Consistent, Complete, Correct, and Unambiguous.
Around this time, a group of rebels in Utah created the Agile Manifesto, which made the claim that responding to change is more valuable than following a plan.
Eighteen years later, I’ve come to believe there is a better way to develop software, and applying it to distributed teams is easier than many people think.
Let’s talk about it.
Take any part of the development process – say testing, my bread and butter. Your team has it all figured out, with a magic automation tool. By magic, I mean exactly that. Push a button and you will get instant test results, clearly articulated.Not fast — instant. I’m talking about magic.
The automation tool never makes a mistake. It magically knows what a change will be and how it should impact the system, so it never reports a false error when the system behavior changes. Because of this, it needs no maintenance. Just change the code, click the button, see all the problems.
Now, will having that accelerate your software delivery at all?
In many cases, the answer is “no.” Even with the organizations that benefit, the benefit might only be a two to four percent increase in throughput.
Here’s why, and how to do better.
Prior to the release of the Nest Thermostat in 2011, the Internet of Things was mostly hype. Refrigerators that texted you when milk spoiled were not really possible. Lawnmowers that texted you they had not been used in awhile were less useful than, say, looking at the grass.
Today, internet of things devices are real, and valuable.
The only problem is getting them to work.
Hard-coded test directories on the server.
Hard-coded test databases in the code.
Exception handling that couldn’t actually handle the exception at the level it was called for.
I reported the errors to my management, and they replied that I did not understand the code review process. It was not my job to give an up-or-down vote, but instead to review the code. The code review had occurred, therefore I needed to check the box for code review and move the code into production. If it were ugly or not was merely a matter of my opinion.
If only I had known what to say — that ugly code is bad code. Code so complex I cannot understand what is happening.
Code that bad will have errors that we cannot even find, because we cannot figure out what the code is doing.
How does code become ugly?
One change at a time.
Let’s talk about that.
The path to leadership in software usually looks something like this. A junior programmer takes a job out of college and works diligently. Every couple of years, that person hops to a new company to get a new job title and an accompanying raise. Eventually, they find a place to settle in for a while. They work into the senior role, get antsy for what ever is next, and poof, they are given a promotion and become a newly minted ‘lead’.
In that time, our developer friend learned to become competent at their trade (hopefully), became familiar with a couple of code bases, and probably has a reasonable professional network. But, where does the leadership come in?
Somehow, sometime, the concept of a spike got introduced into agile practice and language. The general idea is this; we need to make a product change but aren’t quite sure what direction to take or how to find that direction in the first place. A spike is the black flag we raise to say we need time to work on something that isn’t _obviously_ productive. The end result should be information and a general idea of what we need to do next, not code and software in production.
The rules are simple, the implementation is not. What I usually see, is spikes that result in a day of reading API documentation. So, the question then, is when is it a good idea to spike something out and when might we be better served by digging into the work and learning from that experience?