“Technical debt” is a term used in software development to describe delayed maintenance costs caused by initial tradeoffs between quality and speed. It’s a common metaphor on engineering teams as it makes the sometimes opaque costs of technical decisions easy to understand across the team. Technical debt functions just like
Category: Software Engineering
Some executive-level roles are difficult to define from an outsider’s perspective. Two positions that can be difficult to distinguish are that of the VP of Engineering and the CTO. As a growing company or aspiring IT executive, you need to know: What is the difference between a VP and a
Since Uber’s first ride request in 2010, the tech giant’s cutting edge engineering has revolutionized the rideshare industry. While today’s tech stack may be well equipped to build an app like Uber, the location-based startup was the first of its kind to put a taxi app with real-time GPS in
Developers often decide whether to build monolithic or microservices architectures based on personal preference. This article tells you how to design the best platform for your client by considering both methods.
Monolithic all-connected platforms might serve a startup’s needs, but they often have problems with scaling to support growth. Architectures built with modular microservices work well for bigger enterprises, but they might be overengineered to require more resources than a startup can spare. This article explains how to incorporate both these build approaches to design a functional strategy from the start that evolves to fit each point in a project’s lifecycle.
A bird-eye view of the machine learning landscape.
The main goal of this article is to cover the most important concepts of machine learning, and lay-out the landscape. The reader will have the vision to understand what kind of solution matches a specific kind of problem, and should be able to find more specific knowledge after diving into a real-life project.
I’ll start with a 60 years old definition, but still valid today:
The name is pretty self-explanatory, and the definition reinforces the same concept.
Culture is the way a company does things, its processes and values, and how it generates outcomes. It’s never easy to build, share, and promote knowledge across a medium-sized organization. That task requires leadership, rules, a strong culture, and having effective systems in place.
I’ve always been passionate about how knowledge sharing has a multiplier effect on the quality of what each person can deliver. I’ve seen junior developers, after a just few weeks, deliver higher quality work than what I could have produced years ago — even in a nonchallenging environment and even after years of experience.
Why you should stop blaming a programming language for your low quality work.
I’ve heard too many times that Ruby on Rails (also called RoR) doesn’t scale. Guess what? Java doesn’t scale, .NET doesn’t scale, PHP doesn’t scale, and Node.js doesn’t scale. No programming language scales if you build terrible software with it.
In this article, I focus on Ruby, but the information is valid for almost any programming language. If you typically benchmark Ruby against other languages like Python or C++, it’s probably slower in most contexts.
The real question is not how long it takes or how many resources it consumes to run some algorithms like regex redux, binary tree searches, or reading DNA sequences.
An in-depth analysis of your system’s health.
For many projects, clients hire us to only run code audits. In other cases, we inherit legacy code, and going through a code audit is a requirement for working with us.
With time and repeated experience, we refined and strategized our audit process. It’s now a distinct work product that we offer to clients on its own.
As said, we often get projects that were created by other teams — sometimes in-house techs and sometimes offshore providers. In these cases, clients ask us to just take over the work or to only fix the problems. But we don’t work like that.