Category: Editorial

  • Simple(r) Coffee

    Starbucks has too many order combinations. This article about the challenges for their new CEO notes there are over 170,000 combinations of things customers can order. As someone who has visited a store often and stood behind someone placing an order, that sounds like an accurate number. Sometimes I hear people order things to drink that I had no idea were even possible.

    When there are too many choices, sometimes there can be a delay as the person tries to process the information and make a decision. Some people can’t make a decision. Others enjoy the variety and keep making different decisions each time. That’s fine if you’re visiting a restaurant, but it’s less useful if you’re building software.

    I have worked with people who struggle to decide on an approach to solving a problem. In the C++ world, I’d see people struggling to organize classes and members, sometimes spending too much time researching and comparing different methods. They debate when is private or public appropriate, when do we need a superclass or subclass? We would see some paralysis by analysis from certain developers who are endlessly searching for the optimal approach.

    Other developers might change their approach constantly, resulting in a lack of consistency across the codebase. In the modern world, I sometimes see users experimenting with different libraries or packages (or data stores) with each new project. They might be consistent within a project for a period of time, but since many teams often shift to different projects over time (or maintain them), how helpful is this? If each new project looks different, we spend a lot of time on developers getting familiar with the technology.

    I have tended to adopt the philosophy of strong opinions, loosely held. In other words, I’ll pick an approach/platform/technology/etc. and stick with it. Moreover, I’ll ask everyone on the team to stick to a similar method of coding. If we need to change, then we can evaluate the proposed change, performance test it, and if we decide it’s better, we all adopt this and slowly work to refactor old code as we have time. We never have time, so we only refactor when we have to touch old code for some fix or enhancement. However, when we do touch old code, let’s improve it.

    My preference is to allow a limited set of technologies in our company at any point in time. We need a process to add or remove something, but this ought to be a decision made to limit our range of technologies and required expertise. I’m not against Python or PowerShell or MongoDB or any other technology, but I don’t want things adopted because an individual prefers that technology or thinks it works better. They need to prove that there is a good reason to others, and as a group, we agree that the value of adding a new technology is worth the burden.

    Otherwise, we end up in the situation I see often in job descriptions: with a requirement that new hires know dozens of technologies at an expert level because we don’t have that person on staff.

    And we’ll never find them.

    Steve Jones

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

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

  • The Lesser Used Functions

    Recently, I reviewed an article that examined the bitwise functions that were added to T-SQL in SQL Server 2022. As I was looking over the article, I started to wonder if anyone was using these in production code. I used to do bitwise work early in my programming career, when memory and space were tight. However, it always felt like I was hiding some information that a subsequent developer (or my future self), might easily miss.

    I looked through some other changes to the T-SQL language in the last few versions and made a list. This week I wonder if any of you use these functions in production code?

    There are some interesting changes in here, and I can see the use for these functions, but I suspect these are specialized functions built for specific situations (or customers). I don’t expect many people to use them outside of those situations, but maybe I’m wrong. Perhaps some of you like doing bitwise operations, you like the logical CHOOSE/IIF, or maybe you can stomach approximate calculations.

    I’m glad that the T-SQL language continues to grow. I would like to see more changes that ease the development of database code, though I would like Microsoft to ensure these new functions perform well. Some of the changes added in the past haven’t done so, especially when a dotNet function is wrapped with T-SQL. Performance matters and many of these functions will be called in queries that need to compete a result with thousands of rows.

    Let us know today if you’ve found these functions useful in your work, or if there are changes made in the past that you would like to see improved.

    Steve Jones

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

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

  • Adding the Right Value

    I caught this post about a career presentation from Kendra Little and it resonated a bit with me. The summary of the post (it’s a bit long) is that there is valuable work that supports and benefits a team of people, called glue work. However, glue work isn’t necessarily technical and it isn’t necessarily recognized as valuable by management. In fact, it might unintentionally lead you from a career in engineering to one in project management.

    I haven’t been someone who has been marginalized in positions, who has been taken for granted or expected to do certain tasks. I think some people get taken advantage of, and this is especially true for women, who both volunteer more and are volunteered by others more for these tasks. While I have been quick to document decisions or actions, and sometimes help out with project work, I do that in addition to any technical work. I’ve felt that as a developer, my job is to produce code. If I can help with other things, then I’m a Developer+, but I ultimately know that code my clients can use is what matters.

    I think that people sometimes mistake valuable work for the team with valuable work for the people looking at the team. They know teams fall apart because someone doesn’t do the glue work. Or they have a s*** project manager who isn’t managing the project. I think that is very common, and because many of us have an “I need to succeed” mentality, we sometimes stop coding to pick up other tasks, essentially volunteering to be the pseudo-project manager or team manager. That’s fine, but if you fill your days with non-coding tasks, you are not moving toward senior engineer status.

    At the same time, I know that many of you don’t want to work long hours, nor do you want to let tasks drop that need to be handled. There’s tension there, as either the employee feels overworked and taken advantage of, or they work themselves into burnout.

    Sometimes there isn’t a choice and your boss might expect you to work extra hours on tasks adjacent to or related to your work. I have seen a few people work for one of the big-name tech companies where employees had tasks outside of their normal work that they were expected to complete outside of their core 40 hours. If you have a boss like that, I’d look for a new position. That’s my advice. I’m happy to work extra hours in limited doses, but not on a regular basis.

    I’d say the same thing if your fellow employees don’t step in and do their share of the load of glue work. If we’re a team, we all do those things. If we don’t, we’re not a team, and I don’t like working in places where we aren’t a team.

    Whatever you decide to do, make sure that you are clear on what is expected of you to get that raise/bonus/promotion and focus most of your efforts there. It doesn’t matter what you think is important; it matters what those who make decisions about your career think is important.

    Steve Jones

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

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

  • The Rise of Data Centers

    For the last few years, we’ve seen no shortage of cloud migration stories and felt pressure from management who wanted to migrate our systems to the cloud. It seems that almost everyone I speak to has a story of having to move a system out of their owned or leased data center into a public cloud from some vendor. A lot of this is the movement of VMs from one place to another, which has me scratching my head. If we’re just running VMs, surely we can do this cheaper in our own data center.

    Perhaps, though there are a lot of costs to setting up or running a data center, and it’s not easy getting a system in place that allows a bit of self-service for our customers. Especially while ensuring that images used are properly patched and secured, while ensuring lots of easy connectivity to storage that can be reconfigured easily. It might not be worth the effort for a few dozen VMs, but if you have hundreds of systems, maybe it is.

    Maybe it’s happening. I keep seeing stories about repatriation from the cloud. I also caught the global data center trend report, which shows a lot of growth in the data center world. Vacancy rates are low and there is continued demand for building more data centers. Some of this is due to public cloud providers, some is from AI companies who need lots of power and GPUs, and some is from private companies looking to collocate their systems.

    The world is becoming more and more dependent lots of servers in data centers. I expect that we will continue to see more data centers built, but I expect fewer and fewer private, corporate data centers. More than likely all of us will use someone else’s data center, even if we choose to own the computing systems. Even Basecamp, which left the cloud, is using a collocation facility for machines, which means they are using a facility owned by another organization and shared with other clients. However, they own the servers they use, which are just located in someone else’s data center.

    If any of you have private data centers, my guess is most of those will slowly fade away over time. The cost of running them privately will exceed that of what vendors will charge. Data center vendors can spread the cost of buildings, power, networking, cooling, etc. across multiple clients, often hundreds or thousands. While you might not be in the cloud, and you may still own your own computers, you’ll likely store and connect them in someone else’s data center.

    That means that most of us will need to be comfortable with limits on the hardware deployed and amount of upgrades available. In the cloud you’re limited to what vendors provide. In our own collation spaces, it might be what our core IT group makes available. I still expect database servers to be among the largest machines available, but there will still be limits to what most of us can provision. After all, most IT groups still want some standard configurations shared by most of their servers. That might be an interesting trade-off for some of us as the cloud might be more or less preferable in certain situations.

    Steve Jones

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

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