Malcolm
Anderson
Husband,
father,
coder,
world traveler,
teacher,
systems thinker,
problem solver.
PAST EXPERIENCE
Note: The opinions expressed in this blog do not reflect the official or unofficial belief or policies of any of my past present or future customer, employers, employees, or students.
Sometimes the opinions expressed do not reflect my own beliefs or opinions either. The contents of this site are a snapshot of my thoughts and opinions at the time of writing.
Summary
In the early days, new features are added to a project hourly. But after a bit, it slows down, to a new feature every day or two, and then every week or two. Soon you aren’t happy getting 2 new features a quarter, but with all the bugs, 2 is better than zero.
The Dev in DevOps brings a programmers eye to the development process, from business analysis, to deployment to the help desk.
The Dev in DevOps brings practices, and the discipline to follow those practices to your organization.
The Dev in DevOps finds those people who can make those changes that start to turn the large container ship that is your current set of processes.
A wealth of experience across all aspects of the both the startup and enterprise environments provides the experience to spot the small steps and team members who can safely take those steps to start building a DevOps practice. A practice that isn’t just rebranded waterfall. A practice where small changes once again get implemented quickly and safely. Like in the first days of the project, new features start being implemented in a steady process.
History at 30,000 feet
High School, the Marine Corps, and College Dropout
My first coding experience was sitting around a TRS-80 with 3 classmates, doing “Mob Programming” long before it was a buzzword. And then I was off to the greatest problem solving school in the world, the cold war Marine Corps, an ancient anti-aircraft system and learning troubleshooting under Top Spade, one of the greatest teachers to ever grace this world. From there I was off to college and other adventures.
Athena Software – Cofounder and CIO
My first startup in 1989 was literally “working in the kitchen” I was the entire technical wing of the enterprise. Business Analyst, Architect, Designer, Developer, DBA, Integration Manager, Tester, Build Engineer, Install Engineer, Shipping Department, Tech Support and Customer Service.
This is where I learned:
“If the code won’t deploy, that’s a developer problem.” and
“Testers are a luxury, if there’s a bug in the code, that’s a developer problem.”
Dot Boom and Bust – Programming, Business Analysis and Reports
My second startup and subsequent contracting career took me from 1992 to 2004. Leveraging my leadership experience and full stack development background, a lot of time was spent with a lot of companies. I specialized in working for desperate companies doing short term, well defined contracts. My driving philosophy was a combination of:
“Show me the money” and “Get in and get out”
I enjoyed the thrill of dropping into a firestorm, analyzing the system that had created the firestorm, documenting findings, charting a path forward, and then getting out.
I made a lot of money, and had no shortage of work.
This was the time of the dotcom, Y2K and dotbust.
It was also the time I got married, turned 40 and had my first child.
It was time to grow up and build a career.
Agile Consulting and Training (Accenture, Solutions IQ and others)
From 2005 – 2017, I built and managed CI / CD systems, while traveled the world teaching the “Agile Way” and “Agile Engineering.” Had the privilege of solving problems and doing this work in Bermuda, Canada, the Czech Republic, India, Malaysia and 9 American states.
Eventually got burned out, because (with some very rare exceptions) the people paying for “Agile” were looking for “A good tool to micromanage developers.”
Discovered that
“99.5% of all company dysfunction can be traced to bonus and reward systems.
Discovered that what I love to do is help business people understand the value of “technical debt metrics” and help developers through the treacherous first steps on the path of “agile engineering.” Both subjects are challenging, but so incredibly rewarding.
Operations, ITIL, A+ and SRE in the American Health Care System
Approaching my 6th year working 24 x 7 in operations seeing “the other side of the fence” Provide training around agile engineering practices and DevOps mindset & philosophies.
Was exposed to “Mark’s 5 Laws”
GET THE WEEKLY NEWSLETTER
I want to keep up to date on the DevOps world.
Malcolm Anderson “The DEV in DEVops “
It’s a Journey – Welcome to the ride.
All journeys have 2 beginnings.
There’s the first step of the journey, and then there are all the things that came before the journey.
For the DevOps community, this journey started somewhere after 1843 when Ada Lovelace wrote the first computer program.
All people have points of view, my point of view is that “DevOps” (at least in the HR world) has (incorrectly) become “The cool word for systems administrator”.
For many network ops people and system administrators, their view is that “DevOps is already All-about-programming, so what’s your point?
That’s a pretty wide gap. It’s a gap that I may or may not try to bridge. Either way, not calling out the gap would be wrong.
The point of “The Dev In DevOps” is to give a place for those who want to see the bigger picture to hang out.
For the developers who have an interest in: home lab, their A+ cert, picking up a new language, building their CI/CD pipeline, tuning their code, effortless refactoring, reducing code duplication, building “self-aware” code that fixes itself while sending actionable alarms to the 24/7 people that never get a break.
This is a place for you.
For the business person who has noticed that their coding projects have an amazing velocity of new features over the first 6 – 18 months, but sometime over the first 2 years, the ability to make changes “approaches zero”. It just seems to be harder and harder to get a new feature in.
This is a place for you.
For anyone who has watched project start out with about 18 deployments per year (every 2 weeks for 9 months out of the year), but maybe the project was constantly having high incidents, and the customers were complaining.
Maybe for you, someone suggest that “we eliminate the meaningless churn”, and reduce our schedule to 3 quarterly deployments per year, with hotfixes “as needed.” Maybe now, changes that took 2 weeks to develop prior to go-live, now take 2 quarters.
This place is for you.
If any of the above experiences resonates with you, then you’re invited to come in, pull up a seat, limber up some of your best “lessons laced” war stories and get comfortable.
The DevInDevOps may or may not have the answers you’re seeking, but hopefully with all of us discussing the issues, together we can find some solutions that will help some of us.
(Because we’ve all experienced the chaos that is 99% of of “one size fits all” solutions.)