We’ve started setting up our SQL in the City Summits for 2019 and the first one is London on April 30. I’m going to start making my plans now and hope to see some of you there.
We’re still finalizing agendas and getting some speakers lined up, but if you’re anywhere near London, take a day and come see us talk about DevOps, compliance, and Redgate.
I’ve a fan of Basecamp (formerly 37Signals). I think that Jason and David run their company, business, design, and software in a fascinating way. If I didn’t work for an amazing company (Redgate Software), I’d might see if they want a DBA/evangelist.
Over the years I’ve read a number of interesting posts from them, including their ReWork book, and I’ve learned a lot. They make me think, give me ideas, and a perspective I might otherwise miss about work, life, or something else. They tend to focus on software and since I’m a part of that business, I like reading those posts. I ran across a good one from Jonas Downey called “The right amount of perfect“.
The piece talks about the tendency to want our work to be perfect. We want our new software, class, table, method, stored procedure to be right. We craft systems to work well and meet requirements. Sometimes, perhaps often, we over engineer things. At least, the very talented people I know tend to over engineer. The less talented more often than not just barely get things working, meeting only one particular case, and leave behind a load of technical debt, often in a steaming pile.
Finding a balance for how good our software should be can be hard. I do think that often it doesn’t take longer to write good code than bad code, but it does take time to learn to write better code and practice using patterns that perform well, both in terms of solving a problem and not using too many resources. Early on, when experimenting, it does seem more important to try things, even if they don’t work well. Later, when we are more confident that this particular feature/view/method/etc. is highly likely to be used, we ought to ensure we refactor code or adjust our design to become more “perfect”. We still have to balance how robust we make code given the fact that we always have more work than time, but it should be better than a the first, quick cut at getting a working feature.
The worry I have had, and likely many of you, is that our quick design, our hasty prototype, will be used in production without any time given to rebuild the underlying code properly. That is certainly a concern, and I don’t have a good solution if your management insists on releasing poor code and living with poor performance. The one piece of advice I can give is to learn patterns that work well for queries, for database design, for error handling, or any other task. That won’t allow you to build an extremely robust system quickly, but it can help you minimize the amount of poor coding you do when under time constraints. You’ll write more good code the first time.
Steve Jones
Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.
At Redgate, we do a lot of research. Maybe not as much as Microsoft Research, but we are always trying to investigate more about customer problems and challenges before we build or change software.
Take our survey on SQL Server Configuration Management and you could win prizes. Or a prize.
I’ve never thought about managing an estate, but not that I live on a horse ranch, that has a little more meaning. In the past, I’ve managed hundreds of instances and thousands of databases. That’s certainly an estate, but even when I had 5 servers, that is something of a small estate of things to keep me busy.
At Redgate, we know there are lots of challenges in managing SQL Servers. We constantly have a team of people working on SQL Monitor, and they are releasing changes every week or two. In fact, we just released v9.0 this year, full of enhancements customers have asked for.
In addition to the tactical team that’s building and fixing things day to day, we are doing future research into where to take our monitoring and tuning software. That’s some of what this survey is about. Let us know about which things might help you smooth the process of managing systems.
Give us a few minutes and a little information and take our survey. You might find that a future version of SQL Monitor contains something you thought would be useful.
If you’ve had struggles with database development and had a real world disaster, you could win in a new Redgate contest. We’re looking for the places where old style, waterfall, traditional database development has been a problem. Especially when application software developers have been adopting DevOps, small, rapid release strategies.
Enter before Mar 20 and give us your story. Don’t worry, we’ll anonymize your name and company details. You can enter as many times as you like, but can only win once.
I started working with a small startup company that had 8-10 application developers. We tried to work in a rapid format, releasing a new version of our website every 2-3 weeks. This was going OK, but not great. Often we’d release and developers would go to test their new feature, only to realize that they’d forgotten a database component.
They would roll forward, finding code and deploying a database change during the release process, usually getting the feature working in 10 or 15 minutes.
Until they broke something else because they hadn’t really tested the database component complete. Or they realized they needed yet another database change. Or they had forgotten to code for some edge case that another developer tried during the release smoke test.
When I started, we all gathered in the office on a Sunday night and spent an hour or two releasing code. Not one of my favorite times.
The app developers were using source control, and trying to test, but they often sent code to QA and then fixed things in QA, forgetting that they needed to ensure those changes were deployed again to production.
Across a few months, we implemented what people would not call a DevOps process, reducing our release time to a few minutes, with myself and another developer on the phone, releasing automated changes from a CLI.
Database DevOps makes everyone happier.
Share your story before Mar 20 and good luck.
