Tag: software development

I was listening to someone at Microsoft talk about their product recently. I can’t disclose which one it was, but lots of people use this product and are impacted by changes. The particular thing that caught my attention was that the presenter noted there was a breaking change in the new version for some people. This wasn’t a huge change or one that would affect a lot of people, but it was a breaking change for a few.

Another attendee asked this question: I would tend to do xxx instead of what you showed, so why would you do this?

It wasn’t an antagonistic question, but more curiosity. However, it was a good question since any changes that cause breakage can be disruptive to other people. The thing I noticed was that the questioner’s frame of reference was completely different than the presenter’s. The questioner couldn’t imagine writing code in this way.

As I work with more and more customers, I find that many of them get tunnel vision in that they approach their work or code in one of a few ways and don’t think widely about other approaches. In general, I think that’s a good way to work as we ought to use patterns and avoid anti-patterns in our work. The more we all code in a similar structure and style with the same patterns, the easier it is for any person to maintain the codebase (or infrastructure).

Of course, we have to be willing to add new patterns when we find them and drop older patterns that no longer work (and perhaps refactor the code). That’s another hard thing for humans to do. We rarely want to let go of patterns and who has time for refactoring?

At Microsoft, they have to consider lots of different ways to look at code. I saw awhile back one of them writing that building Windows was like ordering pizza for a billion people. You’ll never get it perfect and someone will always be upset. I get that. I couldn’t imagine making changes to something like Windows, where every little thing upsets some group of people and sometimes those are a very loud minority.

Many of us approach the world in similar ways, and we can appreciate or understand small differences. When we meet someone who sees things very differently, then it becomes hard to reconcile their view with our own. In code, this often means we want to use different patterns than others, which creates a less maintainable codebase.

Communication continues to be one of the hardest parts of building software (and most endeavors). Part of our communication should be to try and understand others’ points of view, get them to understand ours, and come to a shared understanding of how to approach problems. That shared understanding is what helps us build better teams.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

There are lots of software development methodologies. This page lists a few, among them waterfall, agile, iterative, rapid, and more. What’s been interesting to me is that the process of deciding what to code and then whether it works doesn’t change much between different ways of building software.

Instead, the cycle time between when we ask a client what to do and when we deliver it changes. The more agile/lean we are, the lower the cycle time. The more waterfall-ish, the larger the cycle time. I guess that analysis and breakdown of problems into work also changes, as the scope in modern DevOps styles of development is smaller (more contained) than in waterfall.

However, we seem to follow the same steps. In the database world, we might do similar things if we think about how we build data models and code systems. We could get all the requirements and build the entire model, or we could get some requirements in an area, build that, and then ask for more. The former is more of a waterfall approach and the latter more agile/DevOps-y.

Is one better? Not really. I would say they are both situational. In some domains, waterfall might work better. When deciding to build a system to launch rockets, most of the problem domain is known and not changing often, so waterfall type approaches likely work well. Certainly we still went some level of decoupling to take advantage of changes that do occur, primarily in the hardware, but the overall problem remains the same.

However, in many of the business or software tooling places I’ve worked, no one has a good grasp of the entire domain. Heck, I think in most businesses, people roughly know how business runs, but they forget the myriad of exceptions that ensure our environments look chaotic to software, and they often constantly refine (or re-direct) the way the business works in pursuit of their latest goals. At times I’m amazed business runs smoothly, though I think this just shows how much we tolerate variance in business processes that we think are more set and defined than they are in reality.

I am a big believe in loose coupling and accepting uncertainty. I hope for the best, but plan for the worst, or at least, plan for things to change. I like NULLS in databases, not everywhere, but in places because have unknown values. I like agile/DevOps approaches to software because we rarely know all the information about a problem. Heck, sometimes clients don’t know the entire problem or don’t spend time thinking about the entire problem when they create requirements or requests for changes. Therefore, I like short cycle times, with the flexibility to change directions as necessary.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

My wife and I have been thinking about some new audio equipment. We’ve been a little unhappy with our Bose soundbar because of the software flakiness and sporadic network connectivity issues. In looking around, I saw a Sonos product, but after reading a bit about the company’s recent history, I decided to look elsewhere.

Sidebar: if any of you have recommendations that aren’t high-end $$$$ audio, let me know.

I saw this article about some of the problems Sonos has had, and it resonated with me. I’ve been in a place where I’ve worked on software that had a lot of technical debt and needed to be changed/improved to help grow the company. Management was pressing everyone to get the software ready quickly, without more concerns about the customer experience or the quality.

That seems to be what happened with Sonos, where they released new products and new software, with the software missing functionality that their customers needed. There were bug reports, bad press, lower sales, and canceled raises/bonuses. Those last ones, to me, ought to be completely focused on executives and managers, but I’m sure that’s not the case. Management rarely takes the blame, but ultimately they are responsible for hiring, training, steering the employees, and deciding to launch.

The story reads like a summary of The Phoenix Project. Technical debt, poor project management, and pressure to increase sales combine to create a disastrous launch. It’s always hard to know where to assign blame, but clearly, good software engineering wasn’t a priority, nor was reducing technical debt. I know it can be hard to balance the need to alter software with the need to keep it maintainable, but in this case, they made poor decisions.

The article says there were yelling and screaming in meetings, and concerns from developers about pushing back on senior leadership on the timelines and demands. Some of us might have been in those situations, and my experience has been if there is management that doesn’t value software engineering, any particular developer is vulnerable to a layoff or termination if they complain. If management doesn’t value software, they don’t value developers and think they can be easily replaced. I’ve seen quite a few companies start to fall quickly with this attitude when developers are not valued. I also see constant job openings and employees constantly looking for other opportunities at these organizations. People only stay long enough to find another job.

Software is complex. It’s going to have some bugs. There are always tough decisions about which things to work on now and which to delay. I hear those conversations, and I find myself trying to balance the needs of sales and engineering. We need both, and we also need to ensure we can change directions in the future. Paying down technical debt should be a regular occurrence to ensure the software is maintainable and adaptable. I know that when we look to quickly take advantage of new opportunities, this can mean we’re adding new technical debt. Walking that line is the key to success.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.