Whois Asher Bond?


My name is Asher Bond and I am a Software Designer with a focus on solving problems of unpredictable scale. I entered the Technology field in 1995 as a business Internet access solution provider, but also recently did some research and combined practical knowledge from the field today in order to discover a more direct and hands-on approach to software Development which I call Test-Driven DevOps Design.

What's different about Test-Driven DevOps Design as opposed to regular old DevOps

Taking a more direct-path to the software Development lifecycle according to the client requirements, then testing the results after trying many different things quickly is what fundamentally differentiates the Test-Driven DevOps approach from other DevOps approaches which are often very compatible. Service-classes and priorities based on both functional and non-functional requirements are combined to form a Design pattern. The pattern can be delivered or polished into a Blueprint and the blueprint can be delivered. Patterns and blueprints are Templates which can be rinsed and repeated to produce output at a highly efficient rate. Time is managed in a Kanban style, but capabilities are measured as milestones in every iteration to measure velocity and progress. Because failure occurs more rapidly in this approach new capabilities can be discovered faster and improved upon much faster. It is expected that (assuming a steady supply of resources) velocity increases in every iteration. The approach fits into Agile, Waterfall, Kanban and other styles of project management, but be careful about impedence mismatches when fitting any approach into waterfall. The methodologies may vary across domains, programmes, and projects. What you might find interesting is when capabilities are delivered so quickly that people tend to forget what they are capable of.. and that's really the biggest problem with the approach.. it's just too good!

What kind of tools are used in a Test-Driven DevOps Design approach?

Generally if you can take this approach, tools will actually be the output of each iteration, but other tools which already exist may be tested against interoperability constraints in the Design process.

What happens when you try to do DevOps by yourself?

My experience has been that if you do DevOps by yourself, you will be surrounded by a community of tribes (and maybe some teams too) who say it doesn't count. They will try to tell you things like "YOU are not DevOps" but I'm pretty certain of my DevOphood. If you take a Test-Driven DevOps Design approach you can learn very quickly how to measure your own output and improve your own processes by repeating success after a test. The next thing that will probably happen if you publish the output of this process is that others will surround you and invite you to work with them. Working alone is extremely limiting considering the overhead of duplicating efforts, but it is a good way to learn and discover new processes and approaches. For the initial deliverable (a design pattern) working alone is only possible if you are researching what has already happened in the field. Even for the design process a single "DevOp" relies on outside sources in order to form a pattern from a set of requirements. It is advisable to take down requirements from users if UX is an objective. Even a "Lone DevOp" who is engaged in independent analysis is relying on feedback from the environment. Analysts may surround you and want to work with you... sometimes for the right reasons and sometimes because they want to see if this crazy thing actually works or why it doesn't. So you see how common experimentation is and that's because it teaches you the things you can't learn by reading or asking. In essence, when you try to do DevOps by yourself you are surrounded by others who wish not to duplicate efforts.