I am lucky enough to own my own home, but that also means I am responsible for all of the maintenance and repairs. I am ABSOLUTELY by no means an expert on home repair, but I have learned a couple things that I can do on my own, to save a few bucks (and get a self-satisfied feeling of “accomplishment”). It also provides me with some valuable insight on life. Here’s an example.

I have learned that there is definitely a difference between something being “straightforward” and something being “easy”, and this becomes super obvious in home repairs. For example, let’s say you want to move a light switch from one part of the wall to another. If its the same wall, and the spot you want to move it to is right by a stud, then this is “straightforward”. You know exactly what you have to do: Put a new gangbox on the new stud, move the wiring, and just install the switch. It is straightforward, in that you have a clear plan.

But this may be far from “easy”. In fact, it might be downright difficult. It may turn out there are all sorts of studs and pipes in the way, so you cannot easily move the wires. It might be difficult to get the gangbox installed level and in the right spot, for example not be too close to a doorjamb that the switch plate won’t fit. And of course you have to cut up all your drywall, then patch, finish, and paint it (and suddenly you cannot match the paint color).

Alternatively, something might be very easy, like changing a light bulb. Or sometimes something that you are not sure if it is straightforward or not, such as a broken toilet, ends up being very easy (such as just replacing a flapper value).

This concept of “straightforward vs easy” also appears in software engineering. I was working a task recently that was authoring a module, and the specification was very straightforward: make a REST call, pull all the data, and push the data to a database. Extremely straightforward, right? But is it easy? How do you handle REST call failures? Authentication secrets management? Logging of the module event? Pagination if the REST response is large? Management of the parameters to pull the data, especially when it deals with time zones? These types of software development patterns are actually common, and an experienced developer will either instinctively know how to manage these edge cases, or perhaps even have a previous example that they can just copy/paste and make modifications into. But if you are newer to the field, then you probably will either miss these problems until they are caught in testing (which causes rework and thus schedule delays), or these are edge-case defects that make their way into production.

My point is, just because something seems straightforward in your sprint plan, never just assume it will be easy. Because to be honest, when you are working at the enterprise or production level, even the most straightforward things are rarely easy because of the need for reliability, scale, and quality.