What is the correct way to develop a project?

General Rambling

In the short time I have been working on this project I have been trying to ensure that I am doing things correctly. But already I have been asking myself what is the “correct” way to run a project. I have been working in software for some time and have seen many different ideas of the correct method, from an extreme view of Agile where there are no comments and usually no diagrams, to the extreme of Object Orientated Analysis and Design. Where every single step has multiple diagrams in UML and people have spent months planning everything out before a single line of code is written.

I’ve found myself guilty of overthinking the project and stifling what should be a creative process. Now this could be part procrastination which I know I can be guilty of until I have the first part of an application running, or it could be me trying to plan too much which would stop me being able to adapt the application as I go.

So I’m still at the question of what is the right way. Well, to be honest as with most things, the right way is the one that feels right and allows you to achieve your goal. We don’t need diagrams or documentation for everything, but if you get to a stage where it will help, then you need it. By being Agile, you also need that agility to allow you to move to a more rigid system if that is what is most appropriate for a specific part of a project.

Project Update

After looking at using just Git, Visual Studio Team Services or a combination, I decided on VSTS. There were a number of reasons for this, the first being that I like the sprint and backlog items approach that is easy to use in TFS, so using an almost identical system is an obvious choice. I write lists for most things I do, not just in development but when I have chores around the home I write lists. I think it is because I know I will forget them all otherwise (except where gently reminded by my girlfriend), that and there is a satisfying feeling about crossing items off a list, just like there is for moving backlog items into the “Done” column.

I then had to consider source control. Should I stick with VSTS or use Git direct from VSTS. My choice for this was less to do with this project, but to do with my current day to day tasks in my main job. I am currently writing an extension to TFS to manage a custom version of NuGet I developed. Not having done much with TFS Build before having another reason to research it seemed like a good idea.

With this all decided and setup I now have my Visual Studio environments setup a the projects built. I will go into more detail on my next post about my project structure, but the important thing is that I am maintaining my code coverage at > 90% which sticks to one of my goals for the project. But as I get into the more complex parts of the project, the challenge will be keeping that up.

Week One – Initial Planning

I spent a good portion of this week closing off other tasks that I had outstanding so that I could fully focus on Adventure Studio. As part of this I completed a YouTube video on how to integrate the Microsoft Band into a Windows Phone application. This may not seem like it has anything to do with this project, but what I wanted to do was figure out what I could/couldn’t do with creating video tutorials as I would like to create a number of them as part of this project. It was also a task that I have been meaning to do for awhile so wanted to clear that down.

Moving on from that I have been in full research mode, both on the technical aspects and the gameplay specifics for Adventure Studio. Although I have created a number of apps in the past, this will probably be the most complex and I have decided that even though this is an “own time” project, I need to follow the same processes I do in my day to day development work. To ensure that I do this correctly I have decided on the following:

  • Use the Agile Methodology
  • Use Test Driven Development (TDD) with an initial test coverage target of 80%
  • Integrate within source control (Git or VS Online)
  • Use valid UI Testing framework

From my previous experience, when developers create their own projects outside of their day to day employment, see some of the frameworks that we all swear by in work as not being valid for a one or two person project. However, on my last project Beep Fit. I realised that I ended up working following a Waterfall method. I had a list of features that I saw should be included and built for that. As a result the application took longer than originally estimated for, it also resulted in me needing to redesign parts of the application later when I realised that some of the features I was trying to add were just not necessary. So for good measure I have pulled out some of my technical books to review at the start and ensure I am following the correct steps.


Its not all about the technical though! What I also need to do is have a look at the various systems used for creating story based games to ensure that I come up with a good feature list for my sprint planning. This has involved dragging out some old books and games, it has also involved getting an old 1980’s type-in book that I had when I was about 11 but never finished creating that game. This could end up with me finishing off something from my to-do list from 20+ years ago!

Creative Titles

What next?

I am now drafting up my feature lists and setting priorities. If I do this correctly and follow the agile process, I can start getting a basic game ready within the first few weeks and then keep adding and improving the features until I am happy that I have a solid product ready for beta testing.

I also need to investigate using either Git or Visual Studio Online. Although people have their own preferences on source control, I do have some responsibilities for managing TFS in work. If I can use this as a way to improve my knowledge for this project and my standard work, all the better. If not and Git provides the functionality I need then I will use that. So expect my next blog post to be a comparison of the two.