|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
| 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 - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
