Do you speak devtools?
A cheatsheet for business founders — and investors ;) — to understand developer’s lingo
Within the fauna of startup people, developers are very unique animals: you give them a tech issue to solve and they will find one way, or another, to do it:
- They know which tools to use or they will figure out which ones they need
- They are very open to sharing knowledge or even contributing their time to solve somebody else’s problem (ie. would open source exist in the realm of business people?)
- They are self-directed, which translates into their love of self-service solutions: great product, easy onboarding, great documentation, and you‘ll win their trust.
But, if you aren’t a developer, it’s not easy to communicate with them. There’s a full lingo of languages, processes and tools that they use, which might sound esoteric to the outsider.
If you’re a not a developer, in this post I will try to introduce you to the basics needed to follow some of the work of a developer.
If you’re a developer, I will try to help you explain your work to your non-tech colleagues. Please bear in mind that I will do plenty of simplifications to try to explain complex concepts. I will mention some of the most commonly used tools — here or here you can find a more exhaustive list :)
In most of the following sections, you will see that development is almost always about breaking large problems into pieces as small as possible, and then solving those small problems one at a time.
Very simplified, product development could be understood as the output of three functions:
- Product owner guidance: defines what the app or web should do
- Architecture definition: describes how the app should be built
- Implementation: using tools and languages to bring the previous concept to reality
Processes
Development processes could be defined as the glue coordinating the people who are taking care of all those previous functions.
Scrum is a software development methodology that focuses on breaking large tasks into smaller problems and iterating quickly based on the progress done. That approach tries to solve one of the biggest problems in software development: the difficulty in predicting delivery dates!
The most common implementation is to work on daily stand-ups (part of sprints, or cycles of development) where developers check their progress on their last day and re-schedule their workload for the current day.
Kanban is a different system to push the tasks that need to be done today vs what can wait.
Most teams of developers follow some mix between those and other methodologies. In terms of tooling, most common ones are trello (generalist), jira (project management); some new ones try to make the process more efficient (sprint.ly)
Continuous integration, delivery, deployment …
During one of those development cycles, developers will use their favorite text editor (sublime being the winner here) to push their code into a repository (github) which acts as a central storage for your code and coordinates it’s different versions — kind of a google drive storing different versions of a google docs.
After the code is pushed into the repository, a bunch of tasks - that devs will try to automate - happen:
- Testing/quality assurance (QA): which validates that the software does what it’s supposed to do. In case you want to test it with real users and/or different devices, it’s very common to use a marketplace of testers (utest.com)
- Deployment: which ships the code into one your servers - it might be a dev environment, which final users don’t have access and it’s for testing or a production one
If you’re development processes are already working through quick iterations, you might also decide to ship your product to customers as soon as possible, that’s what continuous is all about. Jenkins is still the leading tool, but there’re some promising SaaS alternatives (codeship, travis-ci, wercker, …)
Architecture
After the requirements of a product have been defined at a conceptual level — that might involve wireframes, technical/functional requirements, etc. — it’s time to think how that product will be implemented. The first step is to define the architecture.
At a high level, a software architecture is made of:
Front-end:
The piece/s of software that will face the user and which will be responsible for capturing inputs and presenting outputs — you can think about webs or apps.
Within front-end development, the most common paradigm of development is called MVC, which means breaking a front-end into three main pieces: the model, which manages the data to be represented; the view, which takes care of the visualization; and the controller, which manipulates the data and the views.
The number of languages and frameworks (abstractions of languages which make them more user friendly) is large enough for series of blog post, but the most common ones are: html, css and templating engines for visualization; and controllers and models are developed with javascript and its frameworks (jquery, backbone, angular, and more recently meteor, react, etc.)
Back-end:
The piece/s of software responsible for processing inputs and generating outputs which the front-end will present.
The most common elements of the backend are:
- Databases: there are plenty of them and usually each performs better for a different scenario, but very common ones are postgres and mysql for data that can be represented in tables (SQL), and mongodb and couchdb for data that doesn’t follow a structured format (NoSQL). Recently, graph databases are becoming more common (Neo4j) because they simplify the representation of relationships in data — think about representing your facebook friends and the friends of your friends.
- 3rd party services through APIs: APIs are an interface that allows developers to connect to third party services (ie. query data from your facebook profile, send an email on your behalf, etc.). Today, there’s an API for almost every developer need, but the most well known are: google analytics, mixpannel and segment.io for analytics; sendgrid for email, twilio for telephony, stripe for payments; and if might add from our .9 family: algolia for search and contentful for content management.
And the glue that manages all those elements is the backend code, which can be developed in RubyonRails, nodejs, python, PHP, etc. The choice between those languages will be mostly a factor of the language that the lead developers feel more comfortable with or the language that they want to learn ;-)
Currently, the lines between front-end and back-end development are becoming more blurred due to javascript becoming more and more frequent at the back-end too (nodejs).
DevOps
The piece/s of software responsible to coordinate the servers that deliver the front-end and perform the back-end operations
The databases, the front/back-end code and other components of software (like file storage) are hosted on servers.
Developers can choose between the flexibility (but pains) of managing the servers themselves (bare metal), getting a fully managed solution (IaaS = Infrastructure-as-a-service), or a more rigid but simplified solution (PaaS = Platform-as-a-service). There are significant implications in terms of performance and cost when they choose one of those settings, but the reality today is that most startups choose between PaaS — provided by the likes of heroku, google apps engine; or the ones focused more on mobile dev needs, like firebase or parse — and IaaS — amazon webservices, digital ocean, etc.
Most servers can be simplified as machines running programs continuously (called daemons). DevOps developers and tools take care of monitoring the performance of the software, balancing the workload between machines and launching new ones as required. There’s plenty of tooling here, but the ones that you might heard or seen are probably newrelic, datadog and our ServerDensity who take care of monitoring your servers and apps.
Some solutions are trying to remove or reduce the needs for DevOps, but usually, as soon as the product usage grows, those guys will be an essential part of your tech team.
Microservices
Have you heard your team speaking about microservices? After “big data” this is the new cool tech in town. If you say docker 3 consecutive times, you become recognized as a cool developer ;-)
Basically it means breaking software into modules that are as small as possible (services), so you can replicate them as needed to solve scaling issues — they can also become a blocker if you do it wrong! Those services run in “small” virtual machines called containers and docker is currently the most well known provider of tooling for that.
