How will we be working day-to-day?

I have an “Agile“ approach (based on Scrum) with an emphasis on flexibility, continual communication and creating fast iterations. So we can be continually testing, evaluating and evolving the project to maximise the return on your investment.

Throughout the process I encourage regular, frequent communication and maintain complete transparency.

you can continuously monitor any documentation and research I am compiling before I commit it to code as you will have access to my GDoc work journal. Years of working as an engineer has convinced me of the necessity of documenting every step of the way so I can easily roll-back changes or justify my design decisions;

you can contact me via Hangouts at any time during my work day so we can check-in daily. I work in GMT, but meetings will be scheduled to be most convenient for your time-zone;

you will receive a daily email progress report.

Once you have made contact this is how the project will pan out:

1. Free, initial consultation

We will discuss the project so I can get a rough idea of what you are after and put together an initial feature list (the Product Backlog) from which I can create my initial proposal and suggested budget. We then exchange contracts and move onto the meat of the project …

2. Release Planning

The next stage is for us to plan what will be included in the initial release; the minimum viable product. To do this we will break the product backlog into a series of tasks that we can assign a rough time estimate. Based on these estimates, your budget and/or deadlines we can agree on what the rough goal for the first release. We will work through the project in a series of fixed time periods, or “sprints” (typically a week) where I have got something to demo to you at the end of each sprint, if not every day.

3. Coding/Testing

Nothing gives us a clearer picture that we are going in the right direction than working software so I aim to always have something running for you to see. I will create unit tests as I see fit. We work together to create tests for each new feature, how and if these will be documented and what our definition of “done” is. Automated regression tests could be written if appropriate;

4. Release

We would work together to organise the release of the code to production and possibly staging, environments for which I have a standard checklist.

Can you give me some more details on how you will manage the project?

I use the Plus for Trello browser extension to assign a number of “story points” to each feature or “user story”. This makes a distinction between the comparative difficulty of a story – something people are good at assessing – and exactly how long it is going to take and hence cost – something people are bad at estimating. Apart from coding my time will also be spent on other tasks like meetings, progress reports, design, release preparation, system test, etc. and based on past experience this can anything up to double the actual coding time; in “Agile” parlance a velocity of 50% (1 point divided by 2 actual hours, expressed as a percentage). So plotting points against actual hours in a burn-down chart gives us an indication of when the project will be complete, allowing you to add or remove stories to keep within your budget.

Looking at my demo time-sheet and burn-down chart in a bit more detail: it is based on an actual project with a budget of 85 hours which is half way through. I had initially estimated a velocity of 70% (the requirements were very clear and we had worked together on another project), that is each point would “cost” 1.4 billable hours once all the non-coding tasks had been taken into account. You can see the velocity is actually running at 74% but I would expect this to slow down as the owner starts testing the changes in earnest, and we make any updates and prepare it for deployment.

Typically on a “Scrum” project the velocity would be the points completed in a time-boxed sprint of a week or two, and a fixed number of hours (number of developers * hours per day * number of days). However, although I generally assign a couple of days a week to Apps Script development the actual number of hours per week can vary as I try and reach a significant point by the end of each working day. So I divide the number of points completed per week by the actual hours worked in that week to calculate the velocity, and then express this value as a percentage.

How much is it going to cost?

We’d work together to come up with something we’re both happy with – I try to be flexible here too!

Based on our initial discussions I will provide you with a ball-park figure for the whole project and for each feature. You can then use this figure to fix a budget – or a number of features – for the first release. Once we have prioritised the features, based on business-value and complexity, we will continually monitor our progress to ensure we maximise the return on your investment.

Will I be expected to pay the full rate for bug-fixes?

Every software project is going to involve a degree of research and experimentation. We are bringing together a complex set of tools in a potentially infinite number of ways. We are designing and building a bespoke, custom product because an off the shelf solution does not already exist. Bugs (the software acting in an unexpected way) are an inevitable part of this process. The industry uses a R&D or “agile” approach to overcome this. For example I develop in small chunks, working with complete transparency through my journal and timesheet. Hopefully generating the trust that I have the skills to do the job and create something worth investing in.

So bugs can be due to:

Coding error – This is what could be construed as a developer’s “mistake”, an error in the way the coding language is used or simply making a typo. But with almost 25 years of programming experience under my belt and several years dedicated to JavaScript these will be minimal.

Limitations on what the technology will let you do – Google Apps imposes various quotas on things like execution time

How the technology is going to react in certain situations – the documentation may not describe our particular scenario and we have to try it out before we see how it actually works

New features breaking an existing one – In a complex system a change in one area may have unpredictable effects elsewhere

User Error – Making the code robust enough to cope with every user input has to be balanced against the time this would take, and if it would actually be possible. So the code may receive input that isn’t expected and act in an unwanted way.

I hope this helps explain how bug-fixing is an integral, equally valuable part of software development, along with designing, coding, testing etc.