The days of waiting for direction, standing by to be told what to do, or worst, throwing shit against the wall to get it off your plate and leave it for someone else to clean up, are over.
Today, we decide how we will get there, in synergy, with candor, taking bold steps that are synchronized, not directed, networked.
Reviews are expensive. Start with text, then simple wireframes, once agreed full colour mock ups, and then build it in html, JS, or whatever. Only bugs should be addressed at this final development stage. There should be no review changes after you start building because you caught them all in text, wireframes and mockups. You caught them when it was really cheap and easy to adjust and fix.
Whenever you post for review you open a new google doc if just starting, or the same doc you had the last review in, put today’s date right at the top, make it explicit as to who you want feedback from, you give everyone a reasonable deadline to respond by, and then you list all of the links to the review materials, and right below each link you tell your reviewers exactly what changed since the last review and finally what is still open to be changed or addressed.
As your reviewers add their comments you address and close all of them. You collate the feedback and confirm next steps.
You then repeat, adding the next review, with a date stamp, at the top of the doc, until everyone agrees it looks good and you can move to the next stage; wireframe, mockup or build it. The review doc should read like a diary of the review progress in descending order.
Solving the problem without solving the cause of the problem doesn't solve the problem,
Solving the cause of the problem without solving the structure that allowed the cause of the problem to exist, won't prevent the next problem,
Fixing the structure without knowing who owns it means no one is accountable for its maintenance and it will fail again,
Knowing who owns it without knowing if they have the resources to maintain it, means the whole exercise could be futile.
Figure out who is accountable, make sure they have the resources to get the work done, help them identify what’s wrong with the structure that caused the problem, eliminate that cause, fix the problem that was the result of all of this, and then, if worth it, get an indicator in place that is going to give an early warning if things start to go wrong again.
If we repeat an action more than twice, it should be a defined process.
If we define a process we must start with why? Why do we do what we do?
More often than expected there is no reason to do what we do.
Platform as a Service (PaaS) allows us to create and launch applications in no time at a fraction of what it would have historically cost.
Awesome!
Not so fast.
The provider of PaaS has a goal to make money with their service. They will realize that they didn’t do somethings right and they need to “tweak” what they provide to keep their costs under control, open a new market, or deprecate features that are not used and it no longer makes sense to maintain. Or worse, deprecate the entire platform because it didn’t prove financially viable. All understandable.
However, the platform providers goals don’t necessarily align with the goals of the developer who is consuming the platform. The developer used certain features of the platform so that they could focus on their value adds to their customers. Now that the platform is taking care of that grunt work they are solely focussed on their clients. Except the platform just changed an API, deprecated a feature, etc. etc. Now the developer is working to the agenda of the platform. Their goals for their clients have been side tracked because the platform changed. It may be worth it, it may be a change that helps the developer, but from my experience all too often it isn’t. The developer bought a Platform as a Service to enable them to do something they didn’t want to do. If the platform has done that job they just want to count on it being there so that they can build the truly specialized stuff.
Yes, PaaS allows us to come to market fast, but I am not confident that it enables sustained velocity for the developer who is using it towards value creation for their customers. Choose PaaS with eyes wide open and be prepared for the agenda changes, or probably better, plan to migrate from the platform to what you control once market fit has been proven for your product. Or, bypass PaaS from the start, pick an open source solution for the work you need done, host it on a scalable service, and control all functions of the product that you provide.
Byron Darlison