The database deficit: how full-stack developers’ blind spot harms agile teams
Full-stack developers are a dream come true for an agile team, but many fall short when it comes to database knowledge. Steve Hopkinson, Technology Manager at Publicis Sapient, explores what a database deficit looks like, and how you can avoid them in your team.
In theory, full-stack developers are the perfect agile resource. No matter whether the current phase of development is biased towards the front or back end, they can shift focus to match the project’s requirements, ensuring resources are never underutilized or bottlenecked.
In reality, all full-stack developers have a weak spot. For many, that weak spot is the database. If you have a team of full-stack developers who share the same weak spot, the effect on the software — and on the team’s performance — is amplified.
Truly agile teams need to be agile across the full stack — from automating front-end builds to seamlessly spinning up and scaling environments. An agile stack is only as strong as its weakest layer, so all teams need to have expertise at every layer of the application.
The result: a team lacking database skills will be slower to react, less efficient and harder to scale — all of which can mean the difference between a product thriving or failing.
The following scenario, taken from real-world examples, helps explain:
What does a database skills deficit look like?
It’s your first day on the project, and you’ve been running through the application with two senior developers. What they’ve shown you is cutting edge — a beautifully structured isomorphic React app, supported by a continuous deployment pipeline that runs new commits through a comprehensive suite of tests and environments before pushing the image to production. So far, so very good.
Looking at an architecture diagram, you see that the Node layer connects to a PostgreSQL database. Innocently, you ask how they’re handling schema migrations. The developers share a look, then a laugh.
“We aren’t.”
Over the next week, the red flags around the database start to add up. To set up your development environment, they send you a full, multi-gigabyte dump of the production database — along with a copy-pasted SQL query to bring it up-to-date with the latest live changes.
When you commit some code that requires a small tweak to the schema later that week, the continuous deployment pipeline fails. Fixing it requires a manual update to the database that isn’t completed for two days, delaying the release schedule. Then it takes another day to roll back the change after discovering a production bug.
Digging through the repository, you find a directory called ‘migrations’ filled with SQL queries written by an unrecognized developer. It hasn’t been updated for months. When your work is derailed for the fourth time in a week by database issues, you start to suspect why they left the project.
Many development teams still invest in the skills required to architect and maintain databases, choosing the right tools for the job and integrating them in a way that fits seamlessly into the workflow.
However, some teams that otherwise engage in best practices, are being held back by inadequate database expertise, with consequences ranging from underperforming deployment pipelines to unscalable applications.
Google Trends, a reliable indicator of changing interest over time, shows that searches for ‘database’ have fallen by 80% since Google began collecting data in 2004. How did we get here? How is it affecting teams? And what can we do about it?
Full stack? Not quite…
The rise of the full-stack developer has been one of the decade’s biggest shifts in how software is delivered. With today’s best practice favoring smaller delivery teams, many teams can no longer afford the luxury of having dedicated engineers for each layer in the stack. Instead, a single engineer is often expected to work across the full tech stack.
The surge in the growth of the term ‘full stack developer’ coincides with the first major release of Node.js. The ability to write JavaScript on both the client and server has been a huge enabler for the current generation of full-stack developers. But the language barrier between the server and the database remains — and the conceptual barriers are greater still.
In the last decade, coding has transformed from a specialist technical skill into a fashionable lifestyle choice. With that transformation, the skills people have focused on when learning to code have shifted.
Having taught on both Node.js and PostgreSQL at a leading web development bootcamp, the difference in students’ reactions to the two has been startling. Groups that engage in lively discussions of server-design patterns glaze over at the first mention of a database.
Besides, database management has historically sat within operations rather than development. Many of the details of working with databases have never been part of a developer’s traditional skillset.
Symptoms of a database skills deficit
As a result, some full-stack developers lack core database skills, starting with the ability to choose the right database for the application. It’s not uncommon to find NoSQL databases employed in use cases where a relational database would have been a more appropriate choice, simply because they were all the developer knew. For example, if your application deals with complex multi-table transactions, or if data integrity is at a premium, then a relational database would probably be the way to go.
On the other hand, SQL schemas filled with JSON strings and key-value tables are often a sign that a document-oriented database would have been a better option. In each case, there’s a double cost to the application — first in implementing a pattern that runs counter to the design of the underlying database management system, and second in inheriting the compromises the system made in order to implement the intended design in the first place.
Other skills suffer, too. Data modeling, traditionally the domain of the database designer, is now a core competency across the stack — whether you’re shaping Redux stores or writing models in Mongoose. Those skills can be developed outside of database work. But the experience of implementing and maintaining schemas drives home the value of fundamental design principles such as avoiding redundancy, enforcing constraints and normalizing data.
When it comes to developing a state shape that’s easy to develop and scale, it’s invaluable to have an appreciation of the importance of a well-reasoned data model for your application — regardless of the implementation.
One of the most valuable database skills is the use of incremental, reversible migrations to manage the creation and evolution of a schema. This is frequently neglected by small teams that lack specialist knowledge. Committing incremental migrations to the repository is the database equivalent of using version control when updating your code. So the lack of a comprehensive set of migrations in a codebase should set off the same alarm bells that the absence of versioning would.
From Active Record to Sequelize, many object-relational mapping (ORM) tools have built-in support for writing and running migrations. If yours doesn’t, then there are a number of framework-agnostic solutions, such as Boxfuse’s Flyway or the PHP-driven Phinx. In spite of that, some teams fail to follow what should be an industry-standard practice — with wide-ranging consequences for their development and deployment.
Without committing incremental migrations to your codebase, there’s no way to keep your back-end code in sync with your database programmatically. If it can’t be done programmatically, it can’t be integrated into an automated continuous deployment pipeline.
With a growing focus on the use of ephemeral environments for testing and deployment, being able to spin up a new database instance quickly through executing migrations is becoming a necessity. Failing to manage your database through migrations isn’t just bad practice — it’s a significant barrier to being able to function as an agile team.
What to do if your team has a database skills deficit
Safeguarding your team against a database skills deficit starts at recruitment. A simple database-focused whiteboard exercise at interview will quickly establish a developer’s level of knowledge. One approach is to give candidates a schema diagram and ask them what changes they’d make to accommodate a given feature request. Ask them to explain both the design and implementation.
If your application is live and your development team is already in place, the solution is two-pronged. Ensure the team gains the skills to prevent issues occurring again, and address any existing issues.
Hiring is one way to address a skills issue. But if there isn’t the resource — or the desire — to hire, then training up your existing team could be more effective. The core skills required aren’t rocket science, and there are free online resources that will cover the fundamentals enough to ensure your team avoids the biggest pitfalls.
When a project has been built using the wrong kind of database, or with a poorly modeled schema, fixing the issue can be more painful than persisting with the problems. But if there’s an opportunity for a major refactor, make sure that sufficient time and expertise are invested into getting the database right (and getting the right database).
It’s never too late to start committing incremental migrations to your codebase. Create a SQL dump of your current database’s schema, wrap it in a migration file as an initial migration, then start committing additional migrations to describe any further schema changes. After that, it’s a matter of integrating migrations into your existing development and deployment processes to begin seeing the benefits.
Conclusion
Acknowledging that you have a problem is the first step to finding a solution. It might be painful in the short term to address your team’s shortcomings, but in the long term the costs are eclipsed by the rewards — from a more scalable, performative application through to improved testing and deployments.
Databases may not be flavor of the month, but full-stack engineering and continuous deployment certainly are. Drilling down on database fundamentals may feel like a step backwards, but it could help your team take a big leap forwards when it comes to agile delivery.
