Software Development Life Cycle at Protenus

Protenus’s software development life cycle is the process through which our platform is created. Its progression can be roughly described as the following phases: planning, creating, testing, deploying, and maintaining. At Protenus, these phases are flexible and often overlap. Let’s have a look at each phase from the software engineer’s point of view to see how they unfold.

Planning

The planning aspect of the development life cycle is the one that touches the most people and requires the most flexibility. Large efforts are driven by input from external stakeholders, multiple internal teams with distinct skill sets, product managers, and designers. Tiny efforts could be owned entirely by a single person. Regardless of the size of work, everything we do starts with our mission and business priorities and can be easily aligned to timely goals.

Planning is often driven by our Product team, which is a subset of Engineering. These folks will uncover novel opportunities by speaking with current or prospective customers, brainstorming with internal subject matter experts, or drawing on their own research and intuition. They will create “epics,” or feature sets, for us to execute which describe the business case and the requirements needed to fulfill it. From this work we can provide input on how best to accomplish it, estimate the effort required, and slot it for development.

Software engineers can also play a pivotal role in planning. Sometimes we have an understanding of a problem to solve, but only a vague idea of how we’ll get it done. One or more software engineers will then perform a “spike,” or a time-boxed period of research intending to answer questions such as: 

• What approach can we take? 
• Is it feasible? 
• What risk factors are there? 

Spikes can generate all sorts of interesting work like proofs of concept or analyses of previously untapped data.

Creating

Protenus follows agile methodology. Once we have a great idea of what we want to accomplish, we’ll create user stories in Jira (Protenus is an Atlassian shop) reflecting the work and schedule them into our two-week “sprints” based on short-term goals of what we want to release. Each sprint results in newly deployed software (more on that later) and concludes with a retrospective meeting where we analyze our successes and failures.

Every day we have a “standup” meeting with our immediate team members in which we announce our progress toward the sprint goal and ask for help if needed. As we complete tickets, we’ll grab the next unassigned item from the sprint backlog.

A ticket will result in one or more pull requests through Stash. We use git for version control and Gitflow to organize our branching. Each pull request undergoes peer review before it is merged. Code review is an invaluable process that helps us ensure high quality, keeps other engineers abreast of changes, and provides a forum for discussion. Our team members hold each other to high standards as we produce code for the long haul. 

Quite often we’ll find that our tickets or supporting epic documentation didn’t cover every last detail; it would be unreasonable to expect that. In these cases, we prefer to empower software engineers to uncover those ambiguities, make reasonable choices, or start a larger conversation if needed. Complex implementation tasks often warrant design discussions with whiteboarding.

Testing

We aim to cover as much of our code as possible with unit tests. Unit testing is part of everyday development and is done by the same software engineers who develop the production code. There are various Jenkins continuous integration builds that kick off in response to our pull requests and our merges, ensuring we have green builds and fresh integration environments. No code is merged without a successful build.

Manually testing our user interface is a crucial part of development. This of course happens as engineers are developing the interface, but we also give our product managers and customer support people a chance to poke at new features before our releases. We seek feedback and pay close attention to detail in order to delight our customers.

Deployment

Each sprint (every two weeks) culminates in a deployment of new software. It seems obvious that we’d need to release new features and bug fixes in order to stay afloat, but careful thought goes into how and when this happens. 

Many customers know that our product is growing its feature set, so they have bought its potential as much as they have its current capabilities. We want to signal to our partners that consistent, well-communicated, valuable updates are on the way.

We also have internal stakeholders who are part of the deployment process, like our Customer Success team and technical writers who ensure that changes to the Protenus platform are documented, communicated, and supported. A consistent two-week release schedule helps us all stay on the same page. In addition to communicating changes ahead of release, we show off newly deployed features during our weekly all-hands meeting.

The act of deploying our software is kept relatively simple by our dev ops team in order to facilitate these frequent releases and make hotfixes possible. We are human, so bugs will inevitably appear in production, despite our best efforts. We patch the most critical bugs with ad hoc deployments outside of the typical two-week schedule.

Maintenance

The Protenus platform is here to stay! As the platform grows, we want to ensure high quality and maintain its ability to change. Bug reports are met with a “thank you” and a timely fix. We budget time to address technical debt, or shortcuts we knowingly took to meet a goal. We listen to feedback that could prompt us to improve existing features. 

In a way, this can be the most meaningful phase for our software engineers. These tasks show us that somebody cared enough about a feature to ask for a cool improvement or that we learned a better way to do something.

Above all else...

Although they sound distinct, none of these phases are executed in isolation. Every single employee of Protenus is learning as they go, so we can’t afford to fully plan a year’s worth of work in advance or delay maintenance. This development life cycle helps us march toward success, but ultimately we are driven by our shared values, our flexibility, and our desire to learn and adapt.

Connect with me on LinkedIn if you’re interested in learning more about engineering at Protenus!