NrvrCommander was different in nature from my earlier real-time, speech, GUI, and document work: More enterprise, less graphical, no assembly code.
I coded NrvrCommander because when we finished a new version server build it took a couple of days until QA could start, often because of test cluster configuration issues. I was annoyed by a lack of predictability and lack of control of man over machines.
I remember my good colleague who had told with apparent authority that kind of automation could not be done. Before starting time-consuming exploration and coding, I had asked questions of the right group of people, each individual in the proper department. I also had searched the web.
When hearing of completion, my team leading colleague perplexedly admitted he “didn’t know that was possible.”
This post is about patterns of interaction around innovation, seeking better collaboration. This post is not about competing with that one person.
While I often prefer using machines for automation, in that setting I wasn’t fighting people’s organizational hierarchy, and watched how well this was getting done with and by people.
Because of competing priorities, and as other DevOps tools became popular, I felt comfortable abandoning further development¹ of NrvrCommander.
I am sure others had similar experiences of making and abandoning. One learns about market, need, features, timeliness, promoting or not.
To get the most benefit from my efforts, I now prefer teaming up with people who move things along, who wholeheartedly use and sell what I create.
Before trusting me, you may hesitate for a moment, wondering: “Why did a person get into a habit of making things others consider impossible to make?”
It was considered virtuous when I grew up to listen to what others say, to improve yourself, your skills, your product. Consequentially, business and life came to resemble the fable of the miller, his son and the donkey: Following conflicting advice leads to suboptimal results.
Repeatedly perceived technical leaders suggested “if you believe [your vision] is possible, make it.” Because of day job responsibilities that meant developing nights, weekends, and vacation time. When ready to demonstrate early versions, other leaders then were ready to identify a weakness: One who develops without having an order on the books, and without receiving initial payment must be a fool. They would not use a fool’s product.
I now prefer working with people and organizations who can agree to roll out and to further develop products and inventions we have in the pipeline.
✉ To join us or to find out about how we can help or work with your organization, contact me.
¹As footnotes, for those technically inclined:
Innovative parts of NrvrCommander that may still be useful were in
- automating use of ssh with password, without keys; and
- cloning and modifying .iso disk images without being root, which required investigating and contributing changes to libcdio.
Other innovation, but probably of shorter-lived benefit, was around configuring then current CentOS, Ubuntu, and Windows.