How to Start a Software Project: A Guide for Junior Devs
“OK, let’s start coding!” However exciting these words are, they are far more comforting when it won’t be you who has to do all the work to kick everything off.
Consequently, starting a software project is a real divider between the experienced senior and the eager junior — and so I recommend that tyro devs get very familiar with all the areas that need to be covered, then have a go with a project that doesn’t have too many eyes on it. Many decisions can be delayed, and certain things can be trivially changed without any side effects, but some items are more expensive to alter later. This post is about where to start, and what bits are best to get right early on.
What Good Looks Like
The number one killer of all projects — even those that are not scrutinized in any way — is that their worth cannot be measured. Even little habits you start for yourself, like going to the gym or starting a diet, get quietly dropped if you see no measurable progress. In industry, unmeasurable projects may look good, but they have an inbuilt kill switch because you cannot prove how they add any value. Remember all those slightly annoying surveys you got in your inbox asking you questions about a website or service you just used? These are people making a solid effort to measure intangibles like “knowledge share.” However hokey it is, try to build a measurement track into your project from the start. There are various things to measure, from early adoption, to unique page views. Conversely, you can measure the decline in a bad thing your project is trying to prevent.
Keeping an up-to-date project wiki is the key to stopping early problems from spreading because of unclear aims. Write down what the project should achieve, the basic components you think are needed, who the stakeholders are and, yes, a few target dates. Novel situations will always occur, and people will do the wrong things — and frankly, some of the decisions you make early on will be faulty. None of these cause chaos. That is caused when people don’t share a strong enough idea of a project’s direction with anyone else. Just writing enough down is quite easy to do, and stems a lot of doubt.
The MVP and the Fakes
The first thing you produce or build should just be in the shape of what you need, but little else. If the product is a website, then it should match the format you want, but just be filled by a “Lorem ipsum” placeholder filler. What matters is that the MVP (minimum viable product) forces you to focus on the infrastructure you need to get in place.
Do you need access to an expensive service? Are you charging money? Is your service time-dependent in some way? In almost all cases you will need to fake one or more components of your project in order to test it, without invoking real-world costs or conditions.
Sometimes quite a bit of work is needed to create the fake environment, but that must be done. For example; while it is much easier to charge money than it used to be, we’ve all seen services that try to introduce charging only to discover that it isn’t so easy to plug in later (because of all the previous assumptions).
Services like AWS Lambda are very good for building cheap fakes, as they only charge when triggered. Fake data also needs to be considered. Testing on data that doesn’t match your product’s actual customer use will inevitably make for bad outcomes. A case in point was an institution that used obfuscated live data for testing. But the data was so heavily disguised that it destroyed the natural relationship between customers (for example, real people live together) and so it caused problems later.
Identities and Who Does What
One of those “hard to alter later on” decisions is forgetting to create email addresses, domain entries and accounts for your project, and instead doing these on your own account details, because you wanted to save time. Don’t do this. It doesn’t matter if you use a domain name or email address that doesn’t match the final identity — it matters that these are not connected to you or anyone else. Otherwise, the whole project goes on holiday when you do.
If you are fortunate enough to have help, then you need to split up the work into sensible portions. Fortunately, the agile methodology works very well for developers on starting projects — because at the beginning you have nothing but a list of tasks to be achieved. People can only take on the tasks if they understand them, which forces you to define them clearly. The same is true if you plan to use AI help — record whatever prompts you use. To start with, this is all you need. The agile mantra is:
Make it work, make it right, make it fast.
So start by making it work with whoever is onboard.
Environments and QA
If you start by understanding what to measure, and where to fake, you will probably find testing and Quality Assurance (QA) follow on naturally. You can use Jira or Trello to communicate with your testers, but whatever you choose should mesh with the tools you use to split up your stories and tasks. The world of containers has massively improved the chances that any environment you build in is pretty darn close to the environment your testers are using.
If you are behind a firewall, now is the time to make good friends with the security team. Otherwise, you will quickly find that you cannot share anything with any offshored testers.
When I say environment, I mean staging, QA and production. If you remove these terms for a moment, we are generally just talking about virtual computing spaces with different configurations. So for example, the QA environment allows your testers to play with the latest stable build and is configured to work with fake services. Scripting to create your environment will involve some type of playbook — make sure you have the skills available to do that.
Developer Tooling
How to actually write the code comes much lower down the priority list than you may have imagined, because it is much easier to setup and change. You can’t blame software developers for wanting to focus on frameworks, coding standards and editors — as that is our stock in trade. Most initial decisions can be altered later. In fact, rewriting your codebase should be something you aim to do at some point; it isn’t something to avoid altogether. But, like going to the toilet, just don’t wait until you have to.
The bigger IDEs tend to include dummy projects and lots of services that can help everyone start. Yes, they want to tie you into their other services, but their utility may be the difference between starting or not. The trick with using any highly integrated services from third-party companies is to make sure you have defined your architecture before you start, so that Microsoft (or whoever) doesn’t redefine your project to suit its tooling. Physical dependency is simple to change, mental dependency is a bit harder to shift.
If you are programming in the open, you will want to use git with Github for your central code repository. But in most cases, you will want to run private repositories with one of the many central repository services. If you know you will produce lots of slow-changing artifacts, then you may need an artifact repository (or DockerHub), and if you are dealing with lots of large files and non-text files (such as large images) then you may need to avoid git altogether and use something like PlasticSCM (which is now within Unity).
Setting up CI/CD
An example CI/CD pipeline; via dev.to
(Unless you are writing Go, don’t expect to see any blue gophers near your screen)
The center of your project will always be the build pipeline — the heart of Continuous Integration/Continuous Deployment (CI/CD). Simply put, you need to create a build from the appropriate code branch of your product or service and deploy it to one or more environments from a single signal. In other words, automate the deployment. This isn’t something you need immediately, but don’t do anything early on to prevent automation later.
Teams still use the open source favorite Jenkins to check out, build and deploy, but there are many other options. If you keep an eye on maintaining the configuration files that work for you, then changing the pipeline shouldn’t be too painful.
Once a basic build automation is in place, you can slot in other services — like code coverage and security testing.
Conclusion
So you’ve defined your project, worked out what good looks like, described what you think the components and processes should be, figured out the infrastructure, got the roles sorted out, checked in the first MVP and cranked the handle on the pipeline.
The important thing about projects is not how they start (no one will remember if all goes well), but how well they are maintained through their lifecycle. And yes, you also need to know when and how to retire them.
