Voice of the DBA

Category: Editorial

  • Reflecting on the Mythical Man Month

    At an event recently, I had a chat with someone after one of my sessions. I had been speaking on DevOps and ways to better structure your team and build software. After the session, one person asked me if I’d read The Mythical Man Month and if I felt we’d gotten a lot better at building software since that book was published.

    I do think we have gotten better, way better, in fact. I caught another review of the book a while back from the Pragmatic Engineer. That review looked at what’s changed in 50 years since the first edition, as well as contrasting the world today. You have to subscribe to read that one, but I’ll give you a few thoughts from me on the book itself and the review.

    Perhaps the most famous part of the book is the notion that adding more people to a late project makes it later. That doesn’t always happen in other fields, where people can tackle separate tasks and get things done. Certainly feeding hay to horses goes quicker with more people. However, in software, things don’t work that way. Perhaps this can work better today if we use microservices and separate architectural sections, but for any single piece of software, this often holds true. Even for microservices I’m not sure it’s true because developers take time to get productive.

    And yet, people still try to add more staff to projects in the hope they’ll complete the application sooner.

    Another great quote from the book is that programmers (developers today) can build castles in the sky. We can use our imagination to create, polish, and re-work in a way that isn’t easy in the real world. That, along with the joy, complexity, and opportunity to learn, are why people program. The Pragmatic Engineer’s view notes that there are other reasons, such as so much of the world uses software that people want to be a part of that, and the career is lucrative. I agree with that for sure. Working with code is a good job in many ways.

    The book notes several challenges to building large systems, such as precise coding, lack of control, dependencies, debugging, and obsolescence from delays. Of these, some are true, but we have tools, like SQL Prompt, that help us avoid poor typing of code (and CI for checking). We also have moved to a much faster pace of delivering parts of a system and evolving them, so we are  often targeting just what our customers need, at an apparent faster pace. I’d also say that being able to deliver something quickly is important, as customers are quick to move on if you cannot.

    One interesting part of the book that isn’t quite so relevant is the discussion about why projects are late. While I don’t know we estimate better, we certainly are better at getting smaller pieces of work done, which might hide some of the delays for larger features. We have so many more ways to track work and ensure we aren’t forgetting what we have planned. There are also many more good managers today that empower their people. These are also the things in DevOps that have vastly improved how we build software.

    Onboarding is a major issue in the book, as finding staff who knew tools/techniques/whatever was hard back then. There just weren’t many people. Today, we struggle to onboard some people, but I’d like to think that it’s not the same as in the past. However, I certainly think database techies in many cases haven’t kept up or learned a lot of core software dev practices, such as version control, CI, and lots of things we bundle into DevOps. At the same time, I think we’ve burdened many people with full-stack development when they don’t have a good understanding of core technologies, like databases and networking. I still think onboarding people quickly is a major advantage for any company that needs to build software and compete with others in their industry.

    In the book, Brooks talks about the 10x engineer, a hotly debated topic in the modern software world. Are some people much more productive? I do think so, though if they are 10x as skilled as many others, I’d argue the others aren’t earning their salaries.

    If you’ve never read the Mythical Man Month, pick up a copy. It’s worth your time as a developer or a DBA.

    Steve Jones

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

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

  • IT Unionization

    I’ve been reading an interesting book that looks at some of the ways that we can better build software in enterprises. One of the side notes in the book is that the tech companies have the funding and the ability to disrupt many other types of businesses, not just technology. Google, Amazon, Microsoft, and others have delved into other types of industries, potentially pushing others out.

    We see Amazon becoming as much a shipping and logistics company as they are a retailer. There was a unionization vote, which passed in 2022. Recently, another one failed. Amazon continues to fight these efforts, trying to prevent workers from collectively negotiating the terms of their employment.

    I’ve wondered in the past if tech workers would ever unionize. In general, we are paid well and have lots of options for work. There has often been no shortage of opportunities for talented workers, though this year is proving tough for our industry. There are lots of people out of work and struggling to find new jobs. While I’m sure some would prefer a union that might better protect them from layoffs, many tech workers are against the idea.

    There is a growing number of tech workers looking to unionize. Inside Google, there is a union for some workers, but not all. That’s unusual, as often all workers in a category are part of a union at a company. To gain employment, you need to join the union.

    I don’t know if I’d want to join a union. I’ve had lots of success and haven’t seen the need, but I do know that I’ve also seen lots of other tech workers pressured and pushed to work long hours, to skip vacations, and other practices that are good for the employer, but not so good for the employee. I’ve seen many people not know how to negotiate with employers, and perhaps a union would benefit most people.

    Would you want to be part of a data professionals’ union? It might give some security and more benefits for many, though not quite as much pay as you might otherwise receive. Maybe more than you get now, as it depends on where you sit in the salary scale at your company. Let me know what you think about unions today.

    Steve Jones

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

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

  • Helping Students with a Data Professional Career

    At a recent event, I had a student ask about how to get started as a data professional. What types of things should they do? What platform should they work on or learn? Where should they focus time? What tools are available?

    Those are all good questions and many of you likely have your own advice. I’ll give a few things to think about today, which are good for anyone that might want to get into the data field. I think this is still one of the better technical careers. I’ve suggested this to my kids, though only one of them went into a technical area. One is a therapist for autistic children and one helps run the ranch while pursuing a graduate degree in literature.

    If I were to give someone advice on how to get started in a tech field, I’d likely start with these items: first, download the free SQL Server developer or Express editions. Most of us run Windows and this is a good place to start. Get SSMS, and learn to connect to your server. If you have struggles, ask a question in our forums.

    From there, I’d suggest working through a book on SQL. Or look at our Stairway series on T-SQL (basic, beyond basics, advanced). Learn to work with data and query it. Learn to download and get datasets into a database, as well as how to query, update, and analyze the data. Those are key skills. If you want to manage systems, try setting up an Availability Group, ensure you have backups and can restore systems, and maybe explore replication and CDC.

    If you want to develop applications, then start building something. Ask a GenAI for help, but produce a working system that lets you analyze some data. Pick sports data, or music data, or something else, and produce an application or report that conducts an analysis of the data. Work with something that’s interesting to you.

    While you’re doing this, blog. Write about what you learn. Build a growing resume that showcases your skills. Chat with others online, build a network of people, and always have an up-to-date resume that you can send out to find a job. Your resume/CV and your blog are invaluable.

    That’s my advice. Anything else you suggest?

    Steve Jones

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

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

  • Changing the Paradigm of Work

    I saw an article on AI usage that is based on an upcoming book that suggests redesigning the world around new tech, not adding it to existing things. The first example is how electricity was introduced to existing factories, but it only provided some incremental gains until new factories were redesigned around electric motors. There’s also an example given about reworking hotels to remove the front desk since that feature isn’t needed. Instead, people could walk in, and an employee with a tablet could find them to check them in.

    I’m all for rethinking and redesigning processes. I do think we have a huge glut of software in many organizations that exists because processes have evolved across time, but not everything and we keep our old software. When we have a new need or want a new capability, we add new software (or add features), but we don’t necessarily throw out all the old software, processes, or habits. That wouldn’t be practical, often because when we implement something new, it might not meet all our needs. Or at least we don’t know it meets our needs at first.

    I don’t love the examples, especially as I see organizations where Teams/Slack are heavily in use (not just in tech companies), and these tools have changed how people work. Not everyone has moved, and there is a lot of document sharing and legacy systems, but that’s also because not everyone wants to or can change at the same pace. However, lots of people have changed how they create, share, collaborate, communicate, and more because of these tools.

    I also think the hotel example is silly (read the article to see more). I don’t need a desk, and often I check in and get my key without ever visiting a desk. However, I do like the desk because when I need something, I want to be able to find someone, not wander around looking for an employee or waiting for them to respond to some page. When there’s a desk I can see someone is there. I certainly don’t want a kiosk with an AI there to queue at to request a person help me.

    GenAI LLMs are going to change work for a lot of people, especially those in tech. I don’t know that we can redesign the way we work now, as the technology is still advancing, and I’m not sure how we will want to integrate agents with GenAI to do work. We have to experiment and find ways to use this tech before we build too much. We also have to see it mature.

    When we do, I bet many more people will start to use AI to generate code, change settings, deploy things, and more. I’m also sure that they will make many mistakes, at scale, and we’ll be using a GenAI agent to undo things, or perhaps we’ll have humans scrambling to fix systems. I wouldn’t be surprised to see the humans commonly fixing things as we might not trust the AI Agent (or our prompting) to fix our mistake.

    If you could redesign work, what would you want out of an AI? Assume that it is at least as competent as someone you work with. Is there a way that a GenAI system would make your work smoother?

    Steve Jones

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

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