I wrote the SQL query in 5 mins. Why does my engineer say it will take a month?

So you’re a woke MBA who learned HTML last weekend, took a class in SQL, or even audited a 6-week Rails bootcamp. That’s wonderful! Learning some aspects of coding is a great way to build cred among your engineers, communicate with them more efficiently, and reduce some of the burden of your overworked engineering team. I’ve never worked at a tech company where the engineering team isn’t the company’s primary bottleneck, so anything you can do that will take work off their plates will increase the amount of time they can spend doing the things that only they can do. My last CEO learned SQL on her own so she wouldn’t have to bother the engineering team with ad-hoc data analysis requests, and by the time I left, she was better at writing complex SQL statements than I was.

But as the saying goes, a little knowledge is a dangerous thing. Much as I’m not a marketing professional just because that witty tweet I wrote that one time got 75 RT’s, you’re not an engineer because you sent an HTML email that looks great in all email clients except Outlook.

Let’s say you wrote an email template that you already sent out to some users, and you want to add a page with the same information to your website. Or you wrote a SQL query that you use for some analytics purposes and now you want your engineer to add something similar to the product – maybe as part of a dashboard, or maybe as a core feature. Easy, right? You already did the hard part!

Not necessarily. That query might be fine for one-off use, but may not be suitable for a production environment. Here are just a few reasons it might not be that simple:

(1) Performance. Your query takes 1 second to run – sounds pretty fast, right? But a second is actually quite a long time for a database, and it could easily cause an outage if it’s run hundreds or thousands of times per second. Your engineers may have set up a data warehouse or other secondary database that you can use without affecting users. A single bad query running on your production database can easily cause a site outage. Your engineers might need to refactor the query, add a caching layer, or process the data offline in order for it to work in production in a way that won’t be catastrophic to your platform.

(2) Edge cases. Maybe you ran your SQL query a few times, fixed the errors you got, eyeballed the results, and called it a day. That’s not good enough for code integrated with a product. Does it work for incomplete or in-flight data? What should happen if something goes wrong – should it retry, display an error to the user, or fall back to some other behavior? All of those annoyingly detailed questions that your engineers ask you about when you give them a product spec are because they have to be coded one way or the other, even if you don’t care which (or if you don’t think you do. You want it the other way if they chose a path on their own).

(3) Multiple platforms. You know that email template you wrote that looked gorgeous? Did it look great on all email platforms? How about mobile devices? Landscape mode too? Accessibility mode? Without explicitly accommodating these and testing them, they might not work at all. I’m not just talking about it looking a little off – it might look horribly broken on one device even if it looks perfect on another.

(4) Interactions with other code. The email that you designed was in complete isolation, but if you need something added to your site then it needs to play well with others. For example, suppose your email uses the same format as your site but with a new button in the footer that should only be added to this new page. Now your engineers need to update the centralized footer code to conditionally add the button in some circumstances but not others. They probably aren’t going to want to copy the footer to create a separate version just for this page (for good reason, engineers have been taught since CS 101 that repeating code is a cardinal sin). Adding a conditional button is a simple example, but it could quickly escalate in complexity in a way that is not obvious.

(5) Testing. A large portion of an engineer’s time is spent testing, even if you have a separate QA team or if you yourself are testing everything they build. Nothing ever works as soon as an engineer writes code; it is an iterative process. Typically, an engineer will write some code, test it out, realize it doesn’t quite work or breaks something unrelated, and iterate. In addition, it is considered good practice for engineering teams maintain an automated test suite, which needs to be updated or enhanced when code changes.

I’ll likely talk more about estimates in future posts as it’s often a source of tension between engineers and non-engineers. These are just some examples of how something that seems trivial might not be as quick to implement as you think.

Hope you found this post useful! Don’t forget to follow this blog using the link on the left, Facebook, Twitter, or LinkedIn. And please send feedback and topic suggestions via e-mail.