Quality Software Starts Before Coding
Basic Software Development Lifecycle tips and skills to live by.
In the massive upheaval the tech industry is experiencing, you might be tempted to start your own software development project. The desire to control your fate can be a wonderful motivator for building a competitive piece of software.
In the excitement of the discovery process, businesses and their initial developer(s) can make decisions that can have ramifications much later in the Software Development Lifecycle.
As you iterate, you’ll want to keep a few things in mind while building out your product.
If you’re a software company in a transitional period, these tips can help prioritize changes you might need to make to infrastructure and tooling to streamline your development process.
Initial Architectural Decisions
There are a lot of very skilled developers with great ideas with the will and capital to build out new software, tools, or frameworks that can add to or disrupt the market.
Before jumping into active development, take a beat and think about a few high level architectural decisions.
Coding Languages & Frameworks
Developers starting with a green field are often faced with two choices: Go with a something they know well, or pick up a language or framework that they’ve wanted to learn.
Neither option is necessarily problematic, however you’ll want pause before making a final decision and do some technical domain research around software already available. Here are a few reasons why:
Matching current industry standards for software development in a particular domain can help with the hiring process later.
Choosing lesser known languages or frameworks can be fun, until you need help. Understanding where the technical consensus is for a domain means there is support available, and possible staff to hire when necessary.
This is also applicable when hiring support staff. Often technical support staff have coding knowledge (such as testers, customer support, infrastructure, etc). Folks with this particular knowledge could onboard faster if current standards are being used.
Ex: I’d like to hire a front end developer and UX designer. Choosing a front end framework that gives you more of a candidate pool can reduce ramp up time.
Active Support Structures
When selecting a language or framework, consider the amount of support available for it. And by support, consider build pipelines, test harnesses and frameworks, infrastructure, and distribution.
All too often greenfield projects have started with newer languages or frameworks only to find themselves blocked when they need infrastructure and supporting tools. My recommendation is to use a language or frame work that has no less than five years of support, an active support community, and supported (and actively updated) test frameworks and/or harnesses that can interface with the latest OS software and devices.
Risk Assessments
Before you go too far into building your software product, assess what risks you might be taking when choosing options for a technical stack.
Different languages, frameworks, and tools have different risks that need to be prioritized during development. To help make informed decisions, make a list of the top three or five heuristics that should be prioritized during the development process.
Ex: Building out a static website requires less security protocols that building a retail shopping site. Depending on your product, you’ll want to prioritize security accordingly.
Known Issues
Rank your developing tech stack by your prioritized heuristics. List known advantages, disadvantages, and major issues (ie - memory leaks, latency, available libraries, etc).
If any of the preferred choices counterman one of the prioritized heuristics, either replace it, or note why the product is moving forward with it.
It’s acceptable to select an option that might pose a higher risk during initial development. However, project managers and technical leads will want to closely monitor the tool, framework, or language base for that risk and plan ahead to upgrade or replace it to better handle a prioritized heuristic.
Ex: Creating a very basic shopping cart doesn’t need an initial large infrastructure foot print to continue iterating on the product itself. However, as the product launches or gains popularity, adding more robust options that can handle scaling and performance should be a high priority either shortly before officially launching or immediately after.
Plan For The Future
Whatever you’re trying to build, set standards for the SDLC (Software Development Lifecycle). Make sure you have a set of review check points. Examples:
Are we updating our infrastructure tools on a regular cadence?
Are we updating hardware to be compatible with infra and building tools on a regular cadence?
Are we removing obsolete tools/software/hardware/protocols regularly?
Are critical libraries and certificates monitored and updated on a regular basis?
Are we regularly optimizing contracts for usage around our cloud infrastructure (storage, CPUs, etc)?
Do we have regular security scans and updates to mitigate risks?
Do we have redundancies for infrastructure and personnel handling that infra?
There’s a huge list you could make depending on what you’re doing. The best guide is to follow your heuristic priorities and get things scheduled on a visible, group-owned, calendar.
Too many times I’ve seen companies have to scramble for something that was “owned” by a former employee and the end result is an outage because there wasn’t redundancy built into their lifecycle.
Like with automation and testing are a lot of trade offs to doing preventative maintenance. It’s all a matter of what you’re willing to risk when something happens. For me, I like knowing a plan is in place instead of having to react to a developing situation I could have prevented.
As with everything I write - if you have any other suggestions or suggested reading, drop them in the comments!