Tag: software development

The IETF has a document, RFC 7282, also called ” On Consensus and Humming in the IETF”, in which they describe how the body makes decisions. This is their philosophy:

We reject: kings, presidents and voting. We believe in: rough consensus and running code.

That is a process that I can get behind. Overall, I don’t like authoritative leaders. I don’t like to be one, though I do recognize as a manager there are times I need to make some decision. Overall, however, I like consensus.

Someone was discussing how to choose approaches when developing software and brought my attention to that quote. With us being remote now, and unable to hum, this person talked about how to solve problems without humming.

This individual talked about identifying solutions in a team, but not taking a vote, or rather, no immediate vote. Instead, they devised a rating system allowing everyone to look at all solutions and rate them from 5 (best solution ever) to 1 (this would be a terrible mistake). They then produce a histogram of the results for each solution.

Once they’ve done this, they can then have people raise issues and debate them. I assume time limited, which is important, but often when we see different levels of support, we may rethink our rating or the merits/detractions of an approach. At some point, they re-rate the solutions and try to develop consensus.

We won’t always agree completely with an approach, but I do think that we can often come to some decision we can support, especially with some rational arguments and reasoning. I’d like to think that I rarely had to overrule an entire group. Building a team means finding ways to discuss, debate, and decide together.

Steve Jones

This year’s pandemic has moved a lot of business to the digital world. We see that with increased ecommerce from many companies, including lots of local business, like restaurants, that have embraced online ordering, pickup, and delivery. In many cases, the companies providing these services were able to scale and meet the additional load, which arguably wasn’t that high for any individual organization.

However, some services aren’t able to handle the loads, especially government services. Recently the Florida voting registration website crashed under a larger than expected load. We’ve seen unemployment sites crash in the US, the contact tracking website in the UK, and plenty more.

I can understand the challenges of government sites, many of which were built on older technology and rarely upgraded with budget restrictions. Investing in new technology is not only expensive, but it can be a huge challenge to ensure systems work through a transition, especially when many users are counting on services to be available.

I do think that the future of much software development needs to be with a hybrid cloud architecture. There are great government secure options from AWS, Azure, and other providers. However, even if you build software that is intended to be in your data center (or a rented one), you ought to be thinking about how to scale it beyond the machines on which it exists, especially if you provide public facing access.

Whether in government or private enterprises, we see the demand for systems grow and shrink rapidly. You can have incredible success, or face shrinking demand quickly. This isn’t like an investment in a large physical plant. The digital world allows us to easily scale up and down, using the cloud concepts and architectures developed over the last decade. Learn about the patterns, and ensure your systems can scale as needed.

Steve Jones

I was listening to someone talk about software development recently and they used this phrase: “are you collecting toxic waste?”. In this case, they were discussing technical debt, but I found the analogy to be good. I’ve often thought that long term technical debt can make a software project extremely question.

The speaker in this talk had two questions, which I found to be good ones for software developer. The first was are you optimizing individual projects at the expense of longer term technical debt? This is a good way to think about each decision you make about how to build a feature. Asking yourself about short term, or limited scope thinking v longer time thinking is important. Often if we take fifteen minutes and discuss the future of a decision with colleagues, we can better view the trade-off. There are good reasons to sometimes implement something in a short term, fashion, but not every time.

Even if we discuss with ourselves, perhaps by writing down the pros and cons, you might think through your issues. I often find that forcing myself to explain a concept helps me better understand it. It also helps me communicate better with others when I have to work through the issues. Of course, it is very easy to miss something or skip steps when you do this for yourself, I really, really recommend you get feedback from another person.

The second question is are you tracking technical debt or finding ways to pay this down? I think this is one that you need to periodically revisit. Between sprints, maybe after mid length period of time has passed, review the items in your system that you’ve compromised on. Maybe you look at code no one wants to touch, or is afraid to touch. Maybe this is examining inefficient code, which is something that is crucial in a database. While a poor query might suffice with low volumes or data, or limited numbers of executions, this can quickly become a problem, especially as the number of inefficient items grow.

The database suffers from often being a bottleneck, a single place where all clients connect. We often do have powerful systems here, and the platforms like SQL Server make efficient use of resources, but bad code and technical debt become problems. I often find broken code in database that can’t even be executed, and along with poorly written queries, this can hamper future development and flexibility.

Periodically review your code, looking for things to remove or improvements to be made. Your future developer self will thank you.

Steve Jones

Apologies – Podcasts are still iffy with my voice and time. Hopefully after Thanksgiving I get back to them.