Abstractions

It is becoming clearer to me, as we progress with BCIP, that this concept of self-service problem-solving/emergent innovation extends beyond the simple boundaries we’ve initially laid out for ourselves. And, the problem of delivering a platform is so much more difficult than I’d really even given consideration to. We aren’t just talking about a technological advancement that improves a warfighter’s operational ability.

We are really discussing a very low-level transformation in how the warfighter approaches their job. In 6Sigma style, we are hoping to empower a renewed determination for continuous improvement. I’ve seen it work in a previous work environment deadset on applying 6Sigma to the engineering workforce. At first, it was an annoying thorn in my routine, having to think about problems in my workflow/workplace and then solve them - documenting to the extremes. Then I began to see opportunities for small 6Sigma projects all over the place. That was the transformation…the vision. Unfortunately, lack of collaboration, or community around the projects allowed for all kinds of duplication, and poor oversight ensured that the processes were more painful than employees were truly tolerant of. The value was real, the implementation poor. But, I now know that I am striving to provide the warfighter with not only that vision but more importantly the tools to implement the vision.

There are a few mountains to climb, without a doubt. In my opinion, the greatest hurdle is making the technologies accessible to the non-programmer, non-coder, non-hacker, at the same exposing enough capability to entice the programmer, coder, hacker to the community. To me, the accessibility is the hard part. Like those who’ll dig through an Excel book to add macros to their pet job-project, I’m hopeful that we can offer up web-based tools that will inspire those same individuals to dig into Ruby, or Flex, or setup a LAMP stack. Perhaps it’ll take a bit of abstraction to get these tools truly accessible by the non-techies. But, I believe it’s possible, and we’re close. Tools like Sinatra help show the potential. The ability to get a web-app “built” with 5 lines of code, including the server is really the base of what we need. Now, imagine a graphical wizard of two sitting on top, that can generate the Sinatra DSL from a few questions?

Abstraction is required. Really that’s what we’re talking about at the data layers as well. Simplifying formats and interfaces to the point where anyone can access them, read them, and use them.

On an internal Yammer feed, there was some great discussion about software engineering practices such as Test-Driven Development and Behavior-Driven Development (BDD). Both are simple abstractions on the idea that “testing” should be a design and development practice, not a post-development activity. BDD is pushing out design practices to the user/owner’s level…allowing them to define expected app behavior. BDD is implemented as next-tier higher language (a domain specific language) that is executable and passes successfully when all expected behaviors are met. It is a basic abstraction of technologies that allows business and quality stakeholders into the processes. BCIP needs the same abstractions to allow warfighters in on the solutions to their problems.