The fabulous adjustment to my working has come forward. As a new employee I’m excited with how I’ve gotten into the new team. As such, I figured I might as well bring some of my practices to light.

In my software projects I follow 3 stages.

1. Design
2. Implement
3. Feedback
4. Repeat or Complete…

This isn’t completely the same as practices followed by other developers, it’s just what got me through my projects to all the way to completion.

Design

For a team based project it’s often seen we could go for an agile Scrum methodology for faster results. The idea is simple for you to understand:

• The Owner decides what your project needs, he chooses a list, or backlog, you need to fulfil
• The Scrum Master, not to be confused with Rugby, works with the owner to plan the timed Scrum’s requirements to complete
• The Team would work together, helping one another out, to fulfil the Scrum’s requirements

Today isn’t to share more about the full Scrum methodology, unfortunately. Today we’ll look at good practices for any software development project you want to make for yourself.

The first step in design is to consider the project you’d like to create as a whole. The easiest way I’ve found I can do this is to spend an hour, or two, to look up whatever might fit the project. This isn’t aimed at copying other people’s projects, no, rather to find what might make your idea shine above the others.

As the example, followed throughout: ‘I’m making a application system to manage the stock of food for our sheep.‘ This suggests looking at what people need, what people are begging for, and what makes this management easier.

When you look at what people need you will get more ideas for what you need your end product to have. In some personal projects, for example NaNoE.V2, you need to understand all requirements people expect, and would love since they don’t have that yet.

When you’ve got enough in your mind for what will fulfil your project needs you can go on to make your design document. It’s a great general practice as it will also lead to new ideas that can help your project out.

…
Test Plan
– [ ] Contact Joe’s Sheep Pty Ltd cc.; Offer free use of our system, we will input current data.
…

Consider a section for the example

These can help to understand the steps you’d need to fulfil the project’s goals. Don’t get confused with the example above being for Testing, rather consider it in the way that design documents will always help you stick to a plan. When a software development project has a plan it can have an improved release to market strategy.

Since we’ve gotten a slightly better idea for what we want in the project, we can create ourselves a design document. There are a few forms we can take, it just helps you get a better understanding of the project. You can easily find templates online, I usually use this one.

You can see you can describe your project in this format and understand what would be needed. Always remember your, and your teams, strengths. This way you can organize who works on which part of your project.

e.g. Consider we choose ‘MySQL Web Service on Azure, C# .Net Windows Desktop management system, and Android Xamarin Application for field report management.’ We already know that Joe Soap can manage the database interaction on all platforms, we know Jane Doe can manage the C# .Net system, and Clint Westwood can manage the Android application in our team.

The design document will give you the space to discuss what’s needed with your teammates and come up with a strategy to implement the plan.

Tons of developers, even towards the end of their university levels to get a degree, forget to take a look at their project ‘as a whole‘. The design document isn’t to limit you, or your skills, for the end product. In any way at all! In the middle of implementation you might realize you can do something WAY better to implement something instead of what’s written here. Always double back, check with the team leader(s), see if it’s a great idea for the current release or if it needs to wait for a future release.

Implement

The implementation can now rely on the design we’ve worked out. In it we’d, for instance, have worked out the data we’d need to work with. This way we can, especially as a team, know what we’d need to implement.

e.g. Joe Soap on database interaction knows we need tinyint for ‘Classes’ of food. For example: {0:Physical, 1:Liquid}, we can add other types if we want to categorize it in even more ways. We also use Decimal(65,2) for weight, in grams, of the food we’re tracking. Sure, we know there are other columns we’d want, this is just a small example.

In interacting with a team we can also get other pointers that would make sense for our project. Since we’re focused on a subsection of the design document we can double check things with the rest of the team if ever needed. This way it can even lead to improved, safer, and more secure, implementation to fulfill the design we’ve planned for.

e.g. Jane Doe points out, ‘For my system built for X we needed to do Licenses, it’s better if we limit the interaction with the Applications to the Web Service goes through Procedures. That way we can make sure we validate the input and output of any data.’ Joe Soap nods, ‘I hadn’t thought of that, let me swap the access methods, what Procedures should I make for you?’

In a solo developed project: don’t worry. It can be achieved by always double checking what you’re about to do. I apologize to anyone who’d take offence from this, at all. Consider last year when .Net 5 and C# 9 hit Release to Market? I’ve already jumped in and love it, I could point out you need to use the init operator for read only variables when you’re working with them. You can easily simplify your designs whenever you’d need.

The main thing is quite simple: you can easily interact with others, look up what you need, and follow the design document. This way you can reach your planned release system for your client(s). I consider it a ‘step‘ alone because of the last step in the cycle, Feedback, as a developer that follows the industry: you might notice something new your system needs. Rather take a note, you can consider it in the next step, our goal is always Release to Market.

Feedback

When you complete the design you’d usually have your team members each take a look, test it in the way they feel it would be used, and give feedback. This could allow any team member to see what they might have accidentally overlooked. Always remember this: we’re human, not a pre-programmed machine.

When you effectively, and efficiently, interact with your team you’ll all help one another avoid missing your intended plans for the release. It isn’t ever to say the project is 100% complete, mind you. As time goes bye please remember this:

1. Technology is upgraded regularly, new methods to use technology as well
2. It might be immediately, it might take a few years, customers will always want even more than your system provides
3. Industries can still change, so even if your system fits the industries needs at the moment it might not stay in their needs forever

At times, I experienced it most for my game development projects, our intended audience can give us feedback. It might be fantastic, it might be to share troubles out systems have, and unfortunately they might be harsh or derogatory. Always stick to your strengths and never drop to their level. Sure, fix things when needed, just don’t let it cause trouble for you, ever.

e.g. Joe Soap hears from Quintil Quintilla that his Android phone isn’t accepted for use with the Web Service. They look at it together and it turns out for numbers Quintil’s device uses ‘,’ for decimal instead of ‘.’. Joe Soap can fix the MySQL Procedures to allow international formats. Quick, simple, not degrading to performance. Sure, Clint could do it in the Android App, he’s on holiday for 3 weeks, this also at least solves the problem without App Store update delays.

In the office environment we can go in several directions from here, the one I love most is internal feedback. Sure, before release we did the same, it’s just slightly different. This time we pay attention to any new changes our system needed above in Development.

• If we ever need to revamp the system to put in a new design and platform we can start again in Design
• If we ever need to fix a bug that needs the system to be redesigned we can start again in Design
• If we get to the point in feedback we don’t need to do much, ever, we can start our next project from the Design step

Take note: every year, odd, take a look at your older projects to consider if it needs any updates, changes, fixes, or new features. It can be good practice to look back at them even if you can’t do anything more.

Afterthoughts

Don’t let it get you down. You’ve got this, you’ll find your solution.

me

Considering I’ve moved from years of development alone into a team with my new fabulous position, the team member I interact most with told me this to end my week getting used to the offices. Especially in a team, remember you can ask others for help. Especially when you’re solo, remember you can ask others for help.

It isn’t that you can’t do what you’re working on, at all. It just might be that you don’t have enough time to read through the thousands of lines of code that they finished months, if not years, ago. A team, and developers you can chat to online, will always be there to assist. I mean, consider how many times similar questions get asked on StackOverflow? Google is your friend, other developers are you friend. Don’t stay stuck on a problem you know others have completely fixed.