Intuitive Programming with Prototyping

When programming, I like to take a high level approach but get to the weeds as soon as possible. It's all about prototyping. Sometimes your customer (the business, your CEO or other person that has influenced you) will need to feel it and see it to know whether they think it will work. How do you get exactly what they want, exactly when it's needed?

Prototype, Prototype, Prototype

Software projects typically fail. This is for a lot of reasons and for brevity I will only hit on 3 today. I will also look at how intuitive programming with prototyping will help to avoid this habit of failure. I will also compare this experience to building a house as we move through, to help put it into perspective.

  1. Scope Creep reference
  2. Overallocated Resources
  3. Poor Communications

The reference here was taking from a project management website. Often, even in agile environments, there are the same failures and stakeholders and leadership still take a traditional approach. So let's look at how we might be able to avoid the top few pitfalls.

Prototyping can solve these issues easily, even in very large scale problems. So the business comes to you and says "man, it sure is painful trying to analyze the results for -some problem- based on x, y and z" and you have an epiphany. Analyze the problem with why is it hard? If this is a pretty straight forward answer (disjointed system or unusable interfaces or non-existent) then you want to understand what a perfect world would look like. Ask them, but just enough to understand the big picture.

Here are some of the issues.

  1. One of the projects was more abstract and they wanted to see the screens of the different parts of the solution prior to biting, with explanations along the way of the bigger picture system
  2. Another project I had was done in traditional fashion (requirements, data model, interfaces, integrations & more requirements) and they ran across a barrier that prevented velocity and didn't fully solve the big problem at hand, and issues faced because of this
  3. A start up was just too fuzzy to really get a grasp of the concepts being pitched in person and on slides (they needed to see something to believe it was possible)

Prototype Proposed Solutions

Before I fully propose a solution, there is one very hard task to get done, and that's recruiting a talented engineer/architect to take this role. Your Prototype Developer. Not just anyone can fill these shoes.

Barely MVP

I like to widdle away all requirements down to the basic principals of the system. How will all of the required components work together? What will the toughest parts of this project be? What don't we need to have initially to show that this is doable? A proof of concept. If we can create this in the "desired" architecture and tools, we'll know very early if it's actually possible. The smaller the better.