Having worked hard to establish myself as an expert in Google Apps Script I look forward to helping you create a product that exactly meets your needs for the best price possible.
Get in touch now to tell me more about your project.
Do you have some examples of your work I can take a look at?
You can see various open-source projects I have created and worked on in the scripts and snippets page and in my Github page. You can also see some case studies about various organisations that I have helped benefit from Apps Script.
This is an example of a design document that I did for an Insurance Company’s quotation app.
How will we be working day-to-day?
I have an “Agile“ approach (based on Scrum and Kanban) with an emphasis on flexibility, continual communication and creating fast iterations. This way 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 will always have a clear picture of the project’s progress as we will share a Trello project plan and I’ll keep an up to date “burn-down” chart in my timesheet;
- you can contact me at any time during my workday 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/Estimation
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, ideally taking less than a day, 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.
Each development task will typically be given its own card, in the appropriate list on the Trello board (Product Backlog, Release Backlog, In Progress, Alpha-tested, Done) and assigned a number of story points:
- 1 point (small t-shirt) = 1 to 2 hours
- 3 points (medium t-shirt) = 2 to 4 hours
- 5 points (large t-shirt) = 4 to 8 hours
These points will be logged against hours, leaving 20% for meetings, design and other unknowns to populate the burn-down chart.
More details of this are below in “Can you give me some more details on how you will manage the project?”
This is an example of a design document that I did for an Insurance Company’s quotation app.
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 will be written if appropriate.
All coding will be done using the best practices I have evolved over 25 years in the industry.
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), although is typically 80%. 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.
Relating points (I can do this as I am a one-man team!) to actual hours.
- 1 point (small t-shirt) = 1 to 2 hours
- 3 points (medium t-shirt) = 2 to 4 hours
- 5 points (large t-shirt) = 4 to 8 hours
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 halfway through. I had initially estimated a velocity of 70% 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.
There is more details on the burndown chart in this post.
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 an 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.
If cost is an issue other things to keep in mind are:
- Quantifying the savings – compare the actual cost savings the automation continuously generates through reduced admin man-hours, against your investment in software development.
- Productising – there are a lot of industries that could find something like [your product] useful, so it could also be worth exploring productising it.
Get in touch now … or read about the various businesses that have already benefited and the time they have saved, or look through some free scripts and snippets.
