Software Development

Our Philosophy

Our Process

In thinking about any process, starting with what you don’t want is sometimes useful.  We don’t want the experience to be miserable and risky for all involved.  Technology should solve real world problems, not create them.  And its important to imagine what success looks like.  These provide some guiding principals and rules.  And because our product cloudstep is all about saving money, we wanted to bring that thinking to our software development process.

We start with a Vision Session.  Here we get people together, learn about the problem being solved and brainstorm how we can build an app or system to solve it.  We keep the problem and the solution at the center with technology firmly in the background.  From here, if it seems like there’s a way forward we move to a solution scoping exercise.  This involves architecture, design and data modeling, capturing all the requirements and designing and budgeting the project.

If we get a green light at that point a series of feature drops happen.  A bit like a sprint, these lead to real deliverables people can experience.  They’re fixed price but variable in time, respecting the reality that people have day jobs as well as the project we’re working on.

Vision Session

The vision session starts with a questionnaire.  We’ll prime the pump for a workshop by asking some pointed questions about the problem we’re here to solve.  This will give us something to work with and prepare but also get’s people’s creative juices flowing.  It ensures we don’t waste people’s time in a workshop.

We hold a two hour design workshop to brainstorm solutions and from this we’ll have enough to propose the next step which is Solution Scoping.  We’ll have a feel at this point how many Feature Drops we think the solution might need and hence what the overall budget might look like.

The sorts of people we want to engage through this are in the business.  The people who live the problem we’re trying to solve.  We need people from IT to place the solution in a context and we use their perspectives to complete the picture.

We don’t charge for any of this.  There’s no value yet so there should be no charge.

Solution Scoping

The Solution Scoping exercise isn’t a massive thing.  As we move through the project much of what is decided or understood may change.  Pretending we can answer all these questions up front is wishful thinking.  So lets set a guiding star, build an initial design and then estimate around that.  We can always triage later around requirements if necessary, parking discovery exercises to later.

This early on there might not be a budget for anything so a $100k scoping and design exercise won’t fly.  We want a short engagement that respects everyone’s time but delivers great value for a modest investment.  We want to understand what the project is or at least where it starts and where it can go.

The Solution Scoping document contains architecture, high level design, data modeling and functional and non-functional requirements.  It also includes an effort estimate and broad organization into feature drops for the various capabilities envisioned.

For $5k that’s outstanding value.

Proof of Value Drop

When we’ve got sign off the first commitment will be a Proof of Value Feature Drop.  Each Drop is fixed price but variable duration.  At the start of the project we want to come out of the gate at a sprint.  We’ll setup the initial development environment (we host that to make it happen faster).  We’ll then build out the data model and bring the thing to life.  This happens in days. 

We get to work building out the capabilities using our Nimbus platform.  It’s a combination of Kubernetes, Django, your choice of database engine and a multi-processing system all out of the box.  We use Visual Studio Code, CoPilot for AI powered software development and technologies like Microsoft Dataverse, PowerApps, Flutter for mobile development and React for native web apps.

Feature Drops  are run a bit like sprints and we work with your project managers to govern the process.

Our aim in this drop is to build something the business can see and play with with many of the key features roughly working or prototyped.  We use this to gain feedback, build momentum and get people excited.  This is great value at $30k and means at this point you can proceed, wait or abandon the work as experiment. You’ve only invested $35k at this point, not $350k to learn it won’t work.

Minimum Viable Product Drop

But let’s assume that this does have legs.  The next thing is to turn the POV into a Minimum Viable Product.  Actually, get it out there being played with to really learn what’s possible or whether we’re on the right track.

In government, putting things into production can be hard but we know which buttons to press here.  The first thing we do is setup the production environments.  They’re a clone of the dev environment, our automation sees it all the same way.  We then harden the solution doing pen testing and locking down authentication.

We spend some time honing some of the features and any tasks we park from the POV feature drop.

Lastly, we handover the solution to the business as a pilot program.  We work with them to put it in place and help them understand how to measure it and determine if it meets the requirements.

So, from concept to something out in the field there’s a total investment of $65k.  Excellent value to show progress in solving sometimes intractable problems.  These solutions might be internal, or they might be citizen facing, anything is up for grabs.

Enhancement Drops

Once we’ve learned what we need to from the MVP additional features can be scheduled as Enhancement Drops.  These have the same $30k pricing scheme as the other drops.  By chunking them in this way we can be sure that investment is placed in the features people need and that we have maintained a focus on the problem at hand, not veered off in another direction.

Its rare that software ends up where it was imagined to go at the start.  Sometimes you don’t know what you need until you see or feel it.  Or as you work more on the problem you understand it in ways you didn’t before.

Software is a tool used to solve problems.  We believe this process respects reality, balances budget with outcomes and leverages technology rather than being a slave to it.

We believe we can help you solve problems quickly and efficiently.  We’d appreciate the opportunity to talk to each of your agencies about the problems they have today.  Give us the hard ones, the speculative ones or even the ones where there’s been failures before.  We’re here to help and we’ve got the right approach to deliver to a budget.

Technology

We’re big fans of python and open source technology stacks. Using this we’ve built a battle-tested platform underneath our cloudstep product for years. We took this special sauce and distilled it into something we use to rapidly accelerate our development cycle while not locking anyone into proprietary technologies. We use mature, tested off the shelf technologies and we assemble them into our application development platform we call Nimbus. We provide the IP for this free of charge to any of our software development customers. We fully disclose how it works for peace of mind and to pass security best practice.

Architecture

• We use Kubernetes as our deployment mechanism. We deploy this in Azure Kubernetes Service or Elastic Kuberenetes Service in AWS.
• We rely on Django for an Object Relational model and in front of this the Django REST Framework to publish models as RESTful Resources. This combination provides a separation of frontend and backend and lets us leverage the extensive security capabilities of Django.
• Python is notoriously slow, its getting faster but we still need some acceleration. We make heavy use of REDIS for this purpose. Its an in memory cache that provides acceleration for expensive operations.
• We use the Celery system fro multi-processing. We try to keep any tasks that might block the user’s experienjce out of the frontend and farm that work to a message queue for processing. This includes interactions with third party APIs or external enterprise systems.
• We build web apps natively with ReactJS and use Bootstrap for the UI heavy lifting. For mobile we use Google’s Flutter which lets us build beautiful, native mobile apps. These talk to the RESTful API we publish with Django.
• We use Platform database series from Azure or AWS. We hate running database servers, everyone does 🙂
• We send all logging and telemetry to Elastic Stack so we can track performance and behaviour allowing us to jump on problems and fix them quickly.

Come inside, its open

Its important to be open and transparent. We make use of these technologies extensively and for more information on each of them please follow the links.