4 ms·
Ugh. Stop talking about automation. Hiring people to automate all the things without any idea about what needs automating is a great way to increase WIP in your
by solatic 7y ago
Ugh. Stop talking about automation. Hiring people to automate all the things without any idea about what needs automating is a great way to increase WIP in your system. All the original practitioners were talking about was taking Lean Manufacturing principles and applying them to software engineering. Not so difficult or crazy, just a desire to have a functioning organization that's always shipping in an aggressive and competitive market, instead of an organization undermined by tribalism and petty politics.
The way you do that isn't by "automating all the things" and "continuously all the things" and "measuring all the things". You do it by getting everybody to put their concerns out of their heads, off the whiteboards, and into code. Code is the only thing that can guarantee that everybody's concerns have been accounted for, including the concerns you didn't know about because nobody can keep 200 people and all of their concerns straight in their heads, while allowing for a release cycle short enough to stay competitive.
That's it! Everything else is execution. Scripts (automation) handle enforcement. Pipelines make sure enforcement is consistent and up-to-date. Metrics make sure your scripts are doing what you expect them to do. Dashboards help convince people that their concerns are actually being taken seriously and the engineering managers aren't just spouting voodoo. Speed is just a side-effect of people being focused on their work and not having to waste time arguing about petty details anymore.
Shell scripting has been around for more than forty years. Modern tools made it pretty, but ultimately you need leadership to make it relevant on an organizational scale.
- jbob2000 7y agoBut I don’t actually care about these things and I don’t care about succeeding or failing. I just care about having sexy projects associated with my name so I can get promoted. (Not actually me, but that’s how people at big companies think)
- maxxxxx 7y agoThis is actually an excellent strategy. Doing grunt work in the trenches is good for business but very bad for the worker.
- cc81 7y agoI don't understand what you are saying more than "Just do the right thing, it should be obvious for everyone". The target audience here is a large enterprise that has value cost and stability for years and has separate Dev and Ops (often not in the same country) and not only follows all those standard processes but has also added a lot of their own written Word documents to the pile. There are check lists, approvals, delivery managers, product managers and all kinds of other managers involved in every release. How do they even start with your advice?
- Spooky23 7y agoYou need to have the courage as a leader of such an organization to put accountability in a place that results in delivery and provide services and culture to get it done.
- deleted 7y ago[deleted]
- cc81 7y agoThere is tons of accountability. That is why you have the delivery managers, the lengthy handovers, checklists and slow processes. So nothing goes wrong and those that are accountable can be cleared from any blame.
- solatic 7y agoYou kind of answered your own question. Word documents aren't code. Take all these managers and get their concerns into code. That means dedicated engineers to turn non-code into code, lower management that can negotiate with stakeholders to figure out what to prioritize, and upper management to get stakeholders to play ball with lower management. Standard enterprise project management, really.
- AndrewKemendo 7y agoIt literally says that in the article: "Most importantly, for DevOps to truly deliver value, it must include more than just tooling and automation—so simply purchasing and installing a solution isn't sufficient. As outlined here, DevOps includes culture, process, and technology."