An Insider’s Perspective on Building Better Software

Physically being in San Francisco this summer has been one of my best experiences toward professional development. As someone who is really interested in the tech culture and innovative technologies, I am thrilled to be in the center of that movement. One of the things that I have actively been doing this summer is using Meetup.com to go to different events of interests, meet new people and learn what’s trending in the industry. Most recently, I was at a Node.js meetup hosted in Heroku. Node.js is an open-source, cross-platform runtime environment for developing server-side Web applications. Heroku, on the other hand, is a cloud platform-as-a-service supporting several programming languages (acquired by Salesforce). The topic of the talk is “Software Development Process”, given by Chris Castle — a developer associate at Heroku.

If you are a Computer Science student like me, you probably know that software engineering is the obvious choice for an entry-level position. Most CS students think that if they can do reasonably well in school, they will be set for an easy career in software development. I agree that CS fundamentals like algorithms and data structure are pivotal to understand, but there are in fact a lot of other challenges that a software developer has to deal with in a professional environment. Chris, with many of years of experience working and leading software engineering team, did a great job describing the process and suggesting a few solutions to make the process more efficient. I will quickly summarize the main points from his talk and add on a couple insights of mine.

The goal of any software development process is to provide better experience for the developers. What does it mean? Code faster? Ship faster code? Ship code with fewer bugs? All of these things and many other small things. There are 7 things that a software developer needs to do on a daily basis, in no order of importance:

· Communicate with other team members (to figure out what to build)

· Design a system to structure the code (to figure out how to build it)

· Deploy the code to the server (make the code live!)

· Review the code for general purposes (check for edge cases, catch bugs)

· Test the code for usability (also known as Quality Assurance)

· Commit the code to a version control platform (typically GitHub)

· Write code (what most CS students think is the only thing they need to do)

There are a lot of things going on in between each of these stages that can potentially hinder the progress of building the software. The question is “How to remove activities that suck?” That’s a broad question but Chris narrows it down to 2 components:

1 — To add grease to a team’s well-worn rails.

2 — To tie communication to the activity.

Sounds pretty intuitive, isn’t it? For the first point, it really depends on the situation for each team. The engineering lead needs to figure out what are constraining the team’s efficiency and comes up with a way to get rid of those. Which ties directly to the second point, because communication is the key to solve it. There are 3 stages during the software development process that require heavy communication: deploying, designing, and measuring. With examples from his work with the Heroku engineering team, Chris digs into each of these stages and suggests ways to leverage them.

Deploying: The deployment process should be dead simple and fast, and there should be a very low bar requirement for it. If you can click a single button to deploy your code, that would be ideal. If your deployment activities can be easily tracked by other team members, that would also be very ideal. So think about ways to make your deployment process a public event and as simple as it can be.

Designing: Designing software is complicated. This is the part that requires a lot of creativity and grey matter throughout the process. The reason is that people conceptualize and develop ideas very differently. One engineer may like to draw diagrams or pictures, another may enjoy writing down in paragraphs, or one might simply want to go straight into coding. Thus, it is vital for the team lead to provide a loosely regulated work environment that fosters experimentation to maximize each team member’s brainpower. The team, as a whole, should spend mental energy on developing the ideas, not on stressing about the unnecessary communication medium.

There’s one specific point I want to highlight from Chris’s talk on designing software, a process called branching. If you are active in the open-source community, you know that when you want to contribute to an open-source project, you need to deploy the code to your local environment, write the code in your laptop, create your own branch within the master branch of the project, submit the code you wrote in your branch, then ask to merge it with the master branch. The admin of the project will review the changes you made and decide whether to merge them with the master branch or not. I recommend checking out Github’s explanation on branching here. There are 2 ways to apply the branching approach to your software design:

· The “many ideas” approach — in which from a single idea, you can diverge it to multiple small branches of ideas, and then assign each branch to a team member to work on based on his/her interests.

· The “evolving ideas” approach — in which one idea subsequently leads to another. There is always a constant stream of evolvement and there is no single centralized idea. With this approach, you need to onboard your whole team at the beginning and keep them firmly grounded throughout the whole design process.

Measuring: This stage combines both review and test activities. Start with a hypothesis based on the question “What should we change and why?” This hypothesis is based on your metrics collected from the review activity (RPM, CPU, RAM, HTTP error count, HTTP error rate, Error details… to name a few). After that, deploy and test your hypothesis. Some key metrics to remember in this stage include memory usage, response time, and throughout (# of requests per min). One quote that Chris mentioned in his talk that I absolutely love:

“Fall in love with your process and the results will come.”

I really appreciate this talk in a sense that it opens up a lot of perspectives on software development. I am not particularly interested in going into software engineering per se, I am more of a product person. But a product manager still needs to be extremely technical and be curious about how engineers can build the product (architecture, tech stack, programming languages, third-party platforms…) Thus, I am glad for the opportunity to understand a bit more about the challenges software developer have to face and work towards becoming an efficient product manager.

If you want to learn more about software development (particularly if you want to go into software engineering), I recommend reading this book “Joel on Software.” I just ordered it on Amazon a week ago and am eager for it to arrive. The author, Joel Sposky — well-known as the founder of Stack Overflow (basically any programmers’ best friend) — compiles all the best practices on building software from his blog into a single book, which has been highly endorsed by many influencers in the industry. So check it out if you have time!