Tag: software development

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

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

I am a big believer in letting teams of people work in a way that allows them some autonomy to solve a problem. I think this is especially important in the software world, where developers need to experiment and learn from the new ideas that they investigate. They need to be able to try new techniques, technologies, and platforms. Yes, that includes NoSQL data stores.

At the same time, this can lead to developers becoming captivated by new tools and techniques, all of which are good for advancing skills and code maturity, but can also lead to a very disparate environment where there are no best of breed solutions, or no standards for writing features. As the number of developers grow, this also raises the bar for each individual to know and understand more languages or technologies.

While I do think it’s easy to pick up logic and syntax, when writing production code, we want to ensure we’re optimizing the way we work. The way in which we might write some code when we start with a new API, SDK, language, etc. is often not the way we’d write that code after a year or experience. At least, I hope it’s not the same way. There are nuances, tips, and tricks in how to better structure code that we learn as our experience grows.

When I was at the Redgate Software office last year, I noticed that there was a short article posted on our internal blog. This noted that there is a set list of tools and technologies to use when building our products. This isn’t intended to be a long term immutable list, and the post noted that other choices are possible, but we want to avoid an unending growing list of tools when we have identified there is a good tool in a space. There is an approval process to propose and new tool and explain why it really is needed.

At Redgate, we’re pretty flexible and open, so I’m sure this isn’t a tough process. However it does prevent every developer from implementing their special little code into a project. We’ve had people use various different data stores, different types of web technologies, and it becomes a maintenance issue over time. Even the VB.NET component we used for years at SQLServerCentral caused headaches as there wasn’t any experience in the company in this language.

I think it’s worth having some light overview that ensures an organization isn’t adding technology just for the sake of making one or two developers happy. There is a finite amount of time to spend learning and growing, and while it’s important that technology workers do this, we also want to developer more experience and expertise in a few areas. Limiting tools and technologies helps preserve a balance that allows for growth, but ensures the expansion isn’t unchecked.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

I’ve never been the guy that produced code the fastest, or the most code in a day. I haven’t been able to show that I work the most hours, or that I even keep great hours. I’m often late or erratic in the times I come and go from work. I don’t show that I am closing tickets in consistent times as I often will be slow to close new issues. I haven’t ever been the employee of the month.

What I have been is effective. I get things done. I leave the organization and the job better than when I found it. I work to deliver value for the salary I’m paid. That isn’t something you can easily measure with many traditional metrics that people use, but there are ways to decide that I’m a good employee. It’s a little ephemeral and sometimes uncomfortable to have an employee that doesn’t seem to fit the same model as most other employees, but that doesn’t mean you wouldn’t want me working on your staff.

This article on measuring DevOps tries to explain how you can determine if your DevOps process is working, which is a similar ephemeral way of working. When we implement DevOps, we don’t have large project plans, we don’t look forward to completing a system. We undertake a set of work, knowing that we don’t have an end date. We just keep doing work and getting things done that are needed. In this case, how can we measure if a project was on time, on budget, and finished?

I’d argue, as would the article, that those aren’t good measurements. Those are the ways we would traditionally look at work, but in software, those aren’t often the things we want to look at. If we deliver software that meets some requirements, but users struggle to use it or complain, is it done? Most management would call it done, just like the airlines mark the plane as leaving on time when it pushes back from the gate. Standing on the runway for 45 minutes doesn’t count against that target, even though I’d call that leaving late.

The article talks about picking things that bother a manager or team members about the software or their process. Some of these are easy, like the time to deliver a new server or recover from a failure. Others that I’ve found to be useful are the time to assemble a release or deploy software to an environment. While we can sometimes play with what these numbers measure by moving to smaller set of changes or altering our process, we’ll quickly find out if we have a lot of overhead in our work by adding these measurements.

What about the software itself? Can I actually compare the time to deliver report a vs. report b? One might be much more complex than the other. That’s true, but we ought to average out delivery estimates over time, and we can certainly separate out query writing of the complex logic against the time required for formatting. In fact, it might be good to start to measure different parts of software delivery to find out if certain people are better at some parts, or if requirements from clients are causing unnecessary delays. I know I’ve certainly had some formatting complaints require more time to get right than the entire rest of the software.

It can be hard to develop metrics that have outcomes and are truly actionable, but it’s a better way to determine if your team is improving. Relying on simple and traditional metrics is lazy, and allows for lots of argument and debate over whether a team is doing well or not. Tackling those specific items that are irritating to management or customers might take some work, but you’ll end up with a list of things that can be targeted for improvement and show progress that actually means something.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.8MB) podcast or subscribe to the feed at iTunes and Libsyn.