Good Practices In Software Development
We recently sat down with Daniel Dubrovkine, head of engineering at Artsy to chat about some software engineering good practices, and to learn from Daniel what tips he can share from his experience building Artsy from day one to its present size of around 50 employees.
As engineers, we are used to objective yes or no answers. But the topic of technical debt is quite fascinating because there is no real yes or no answer or a formula for how much technical debt is ok to accumulate before it begins to damage the business. And there is no business that has absolutely no technical debt.
Daniel talks about two kinds of technical debt. There is the technical debt that occurs from having engineers who are not too qualified to create a particular part of the application, and make architecture mistakes. The danger of having such technical debt is that when you add features upon features on top of a poorly architected foundation, at some point it all crashes and the software just doesn't work.
But technical debt does not have to be all bad. Yes, there is good technical debt. Good technical debt is planned by the software architect to leave ambiguity and unimplemented pieces of the software because the business case has not been completely defined. Once the business case has been completely defined, engineers can then go and write the code to get rid of that planned technical debt. Here is Daniel's video about technical debt.
Source Code Repositories
Any talk about software engineering good practices must mention source code repositories. At Artsy, the source code repository of choice is Git. Many of Artsy's repositories are public on GitHub. In the video, Daniel talks about how Artsy manages its open source projects and some good practices they employ to manage software development with the help of software repositories when it comes to software development, merges, and deployment.
Extreme programming is another fun engineering topic because as some people say, it is in fact, extreme. Extreme programming is useful when the project is very young, and the strategy for the business can change daily. That means that the engineering process has to be able to adopt to the daily business requirements as well.
In this video Daniel explains how Artsy used extreme programming in its early days.
Agile programming is a widely adopted good practice for software development for small, midsize, and large software engineering teams. Whereas extreme programming has software development cycles that can be as little as one day (or sometimes even less), agile development takes a slightly more patient (or sane) approach of adopting two to three week cycles. In the video below, Daniel explains how at Artsy, the entire company (not just the engineers) are on a 3-week cycle, and how the entire company has adopted the agile development methodology.
Daniel Doubrovkine (aka dB.) founded and sold a start-up in the early 90s and completely failed another. He was development lead at Microsoft Corp., Director at Kleiner Perkins Visible Path, Architect and Development Manager at AppSecInc., an Enterprise Software company. Daniel is an open-source cheerleader and avid tech blogger and currently serves as Head of Engineering at Art.sy.
Want to hear from more top engineers?
Our weekly email contains the best software development content and interviews with top CTOs. Enter your email address now to stay in the loop.