Recently, I was talking to Catchpoint’s High School Summer Interns about what software engineering is all about. They’re spending a week at a time with various Catchpoint departments, and last week was with the Catchpoint Technology Group.
If you're a seasoned tech company software engineering* professional, this post isn't for you. It's for the graders who are told that they need to start thinking about college and they have no idea what they want to do, or what skills they have that might apply to a “real-world job”. It’s for the 80%+ of college students who change majors during their college education – because they started studying something and then realized they either didn’t have a passion for it, or, let’s face it – maybe it was too hard.
That’s OK! The whole point of the job market is to find something that’s useful to society that you enjoy enough to do for at least 40 hours per week. As for this post, maybe software engineering is for you, maybe it’s not. The idea is to show how the sausage is made – and that there are many other roles that “coder” inside of a technology organization.
*As we sat down to review this blog post, it was pointed out to me that the descriptions below might be useful to anyone who works with engineers, or maybe just has engineers in their company, or those who just want to understand how the sausage is made, to get a better perspective on the complexities involved. If that’s you, perhaps this post is for you as well.
With the High School interns, we talked about what people might study in school or do for hobbies (computer science or math… although a left-brain/right-brain mix of art or even acting can make great engineers, too!) Then we started talking about what it takes to make software – and what kinds of roles different teams play.
How the Catchpoint Technology Group works
Here at Catchpoint, our Technology Group has several different teams:
Each team is vital to ensuring that our products do what they’re supposed to do, when they’re supposed to do it. Several of the teams are “always on” – if a laptop breaks, Corporate IT is there to save the day. Technical Operations needs to make sure that production systems are working properly. The DevOps team needs to ensure that the CI/CD pipeline is operating smoothly. Project Managers make sure that everything is operating smoothly, applying continuous improvement ideas to the overall team. In addition to these responsibilities, these and the other teams also participate in the Agile Software Development Lifecycle (SDLC).
How does the Agile Software Development Lifecycle work?
Most Agile SDLC diagrams list the steps of the lifecycle as:
- Requirements gathering & analysis
The whole idea behind Agile is to build small pieces and iterate frequently. This works well because very few people can define all of the intricacies of a feature from the start – but they know enough to get started, and then the teams can iterate to keep improving the feature. When it’s ready for customers, it gets released.
Each of these steps has a “main stakeholder” here at Catchpoint – but many of these teams are involved throughout the entire lifecycle.
Let’s walk through how a typical feature is developed
Someone says they want a feature developed – now what?
Product Management jumps into action. Work items are prioritized and defined. In order to define them, Product Managers speak with customers, industry experts, anyone who might be able to help. They might ask Data Analytics for some insights about the feature.
Design typically happens in several different phases. User Experience Designers start to work out how a customer might interact with this feature. Early in the process, Software Engineering and Technical Operations evaluate its feasibility. Security starts thinking about any security implications. Quality Assurance starts understanding the new feature and thinking about how to verify that it’s working properly (creating test plans & test cases).
Now it’s time to create the new feature. At Catchpoint, that probably means several Software Developers with different specializations. Front-End developers need to create the pieces of the software that clients directly interact with – it has to be beautiful, useable, fast. Back-End developers get all of the data to the front end. In the case of Catchpoint, they might write software that measures networks or applications, or our purpose-built Orchestra NoSQL database for fast ingest and query of this data. While the developers are writing the software, Product Managers and User Experience Designers help answer any questions about requirements, and work with developers on different options that might make implementation easier. Quality Assurance is done with the test cases, and Software Developers and Product Managers make sure everything is covered.
This phase is for people who like to break things. Software Developers hand their code (which they’ve done their own testing on) to the Quality Assurance team to verify. The QA team’s job is to find everything that’s wrong with the software before it’s released – anything that makes it behave differently than specified by Product Managers. Performance, functionality, funny colors on the screen – anything. If they find problems (bugs), they work with the rest of the team to verify that it’s a problem and get it resolved. During this phase, there’s Security testing too – it can be in the form of vulnerability scanning, penetration testing, stress testing, or others depending on the feature. All of the testing happens in “Pre-Production” environments managed by the DevOps team, to make sure that any kind of problems don’t impact customers.
At this stage, someone (usually Product Management) decides whether the feature is ready to be released to customers, or if there’s additional functionality that should be added first. If that’s the case, we iterate back to the requirements stage. If we’re done, it’s on to deploy.
Before the deploy phase starts, the DevOps team makes sure that it’s as automated as possible. This team doesn’t touch the actual customer software, but they write software to help deploy and run it once it’s released. This is also where any kind of Engineering Hand-off happens to the Technical Operations and Engineering Escalations teams, to get them ready to take on running this software in production for customers.
The last part of the SDLC is to run the software in production, monitor that it’s working properly, and handle any issues. The Technical Operations team makes sure everything is working properly. If there are issues, Engineering Escalations tries to figure out what’s going wrong, and works with customers, and all the other teams who might be able to help to resolve them.
Time to celebrate!
Now that this feature has been released to customers, it’s time to celebrate! When we’re in an office, it’s usually Donut Plant donuts.
Remotely, we celebrate during All-Hands meetings, and of course in-person celebrations when we get together. Then on to the next feature!