Uncharted Waters

August 9, 2018  9:52 AM

Name It Claim It

Matt Heusser Matt Heusser Profile: Matt Heusser

High Powered Executives Name it, Claim ItI’m sitting in the office of a high-powered executive, and they tell me how the entire technical staff is “bought in to Agile” and uses BDD to enable continuous delivery.

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.

Continued »

July 30, 2018  10:44 AM

Coping With The Crunch

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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.

Continued »

July 29, 2018  11:06 AM

Warming up Cold Calls

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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.

Continued »

July 27, 2018  1:34 PM

The power of the ignorant

Matt Heusser Matt Heusser Profile: Matt Heusser
Management, Project management

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.

Instead of collecting data overnight, in batch, with old-fashioned proom Javascript, aggregated directly into the front end from the web browser. This is going to be great we tell senior management.

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?

Continued »

July 17, 2018  10:13 AM

Optimizing Distributed Teams

Matt Heusser Matt Heusser Profile: Matt Heusser
Agile, remote work

All Alone On Distributed TeamsWhen I was in graduate school at Grand Valley State University, I wrote but never published a paper on distributed teams.

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:

You’re Screwed.

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.

Continued »

July 12, 2018  10:00 AM

The Magic Automation Tool

Matt Heusser Matt Heusser Profile: Matt Heusser
automatic, Automation

An Automation ToolTake 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.

Continued »

July 6, 2018  3:10 PM

The Internet of Things Meets Usability

Matt Heusser Matt Heusser Profile: Matt Heusser
Internet of Things, iot

Usability and the Internet of ThingsPrior 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.

Continued »

June 28, 2018  10:34 PM

Beyond Ugly Code

Matt Heusser Matt Heusser Profile: Matt Heusser

Ugly Code Imagined as a structureTen years ago, I was asked to code review an application. The code was the ugliest I had ever seen – by far. The code was so bad that I could see bugs by looking at it.

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.

Continued »

June 26, 2018  9:01 PM

Building a Lead

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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?

Continued »

June 25, 2018  11:18 PM

To Spike or to Build, That is The Question

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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?

Continued »

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: