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.

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!

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.

So this is my first blog post on here so I will keep it short (ish). So I will start with some introductions, my name is Dave Green and I’m a software developer based in Northampton, UK. In the last year I have created a few small apps for mobile devices along with a couple of websites. This year I have decided to take on one of my bigger project ideas which is to create a WYSIWYG editor for creating old style adventure games. There are a number of reasons why I chose this project which I will address in another post, but the important thing is that my goal is to complete that application and get it released into the wild.

So why the blog? Well, I could just work on this project in my spare time like I have the other projects and when its ready release it. However what I have learnt with just doing some small apps on my own previously, is that there will be plenty of mistakes along with plenty of things that I will learn along the way. What I want to do is document this whole process, look at and research the best ways to approach the challenges and tasks that come up and hopefully help other developers who are trying to develop their own apps avoid the same pitfalls.

Here we are, day 1. I have a name, a blog, a Twitter account, Facebook page. What I don’t have is any code, design documents, UX, marketing strategy, images, audio, followers. So in reality things can only go up from here.

Bizarrely, my first task is going to be some simple branding for social media. If this is going to work, people need to look at this blog or the other platforms I post to and get involved, they wont do that unless I make it look professional. After that, I can start putting the plans in my head down onto posts and work from there.