8 ms·
Corporate legibility for software engineers
- galaxyLogic 4y ago" ... as soon something is quantified, power is given to the measurer." Maybe this is what the "agile wars" are all about. To measure the project progress you have agree on how to measure it, and then whoever defines those rules has the power.
- throwawaysleep 4y agoThis is half of Scrum in my experience. Hours and hours and hours of meetings arguing over the accounting rules for work with the Scrum Master eventually imposing something and using it to beat you down the road.
- indymike 4y agoPower is given to the person responsible for the content of the measurement. The guy making the reports is rarely the one who wields power. The receiver of the reports is the one who gains power.
- now__what 4y agoThe guy telling the report-writer what belongs on the report arguably has more power than the recipient of the report.
- rco8786 4y agoGood article. A lot of this boils down to: you want to be the author/creator/owner of as many docs as possible. Even docs that are a collaborative effort.
- trjordan 4y agoLegibility also increases the ability for a large organization to chase singular ambitious goals. For example: software estimation is hard. It takes time, it's highly inaccurate (frequently by 2x or more), and rewarding good estimation incentives worse software. But having deadlines helps functions like marketing and sales immensely. Marketing can plan effective launches, and sales can guide customers towards new products with minimal lag in uptake. Lots of corporate life is like this. It's a net good if it's used to deliver a better experience to customers. It's a constant fight to make sure legibility efforts aren't being used to hoard power for personal gain.
- hammock 4y ago>It's a constant fight to make sure legibility efforts aren't being used to hoard power for personal gain. At some point in the chain of command, it is always for personal gain. It might be the shareholder at the top, or it might be a middle manager further down the line
- pajuc 4y agoGreat article, very true. "For some reason, corporate legibility tools often have poor UX for those who interact with them who are not administrators." That's because administrators decide which of these tools to use and buy. Tools then focus on pleasing them first. This reminds me of a similar situation with doctors. Some years back there was a great article in the New Yorker called Why Doctors Hate Their Computer. There is a similar dynamic where doctors waste hours on documentation that is then read by hospital administrators who then base their decisions on that. To the administrators this is great, they can see patterns and react to them. To the doctors, not so much.
- Floegipoky 4y agoIn my experience (not the views of my employer) the most important stakeholder for an EHR is the ONC (federal government). Design-by-committee requirements with the happy coincidence of making it almost impossible to innovate or disrupt the industry. They change all the time, requiring a ton of dev effort just to stay in business, which favors giant companies who can afford that "rent". Next is health system administrators (whoever decides whether or not to buy, directly affecting revenue growth). Next is insurance companies. For the amount of revenue they pull in, a shocking amount of practices/hospitals/etc are so financially insecure that if the payers drag their feet for even a short period it can put them out of business. Actual healthcare providers and patients are too low on the list and it sucks.
- beckingz 4y agoMaking work legible can be good for the workers as well! Sometimes. Often not. Jira Metrics / LoC can be used to help justify promotions and raises. Or wrongly deny them!
- BowBun 4y agoThat point is made in the article. > By participating in the legibility efforts, they have the opportunities to make the measures work for them. For example, ensuring that impactful work is appropriately visible to the group that can decide promotions is important.
- __derek__ 4y agotl;dr: In order to master the state's attempts at legibility, one must embrace the legibility and use it to advance one's own aims. I don't think that's exactly what Scott had in mind, but sure: if you want to equalize manager-worker power imbalances in the workplace, it might be possible to work collaboratively to make legibility-creating metrics more accurate and fair.
- zug_zug 4y agoEh, I find this gross. It seems like the premise is "To succeed in bureaucratic companies you must become a bureaucrat". But what I witness is every company that becomes beureacratic dies. And it dies to smaller companies that do more/better with a thousandth the headcount. And I see this natural selection as a good thing. Maybe if your only goal is to be the vulture sucking money out of a terminal dinosaur these are good skills to adapt. But I think it's better to join a place that isn't lost to meaningless metrics and do work that's valuable to the customer and explain it to other humans in human ways (with a reasonable amount of measurement).
- codemac 4y agoBeing able to work in a large organization to accomplish goals smaller organizations could not is one of the greatest accomplishments of mankind. The part that is arguable is whether or not smaller organizations could accomplish the same. I have a hypothesis that it's literally just LOC. The more lines of code, the more SWE you need to be stewards of that code, the bigger the bureaucracy.
- twblalock 4y agoIt’s not LOC, it’s the architecture.
- SethMurphy 4y agoSeems like you both mean the same thing, complexity, a new acronym might be needed "Compound Lines Of Code (CLOC)".
- codemac 4y agoI actually don't, but that's another interesting hypothesis. My hyothesis is that all these "simple" lines of code that are 1000s and 1000s of lines of code, are actually a burden and produce bureaucracy.
- AtlasBarfed 4y ago
- escapedmoose 4y agoIf you have enough business understanding and are interested in the product your company delivers, legibility tools can help you see your personal contributions in context. I think that’s pretty fun. At the least it can lend some more meaning to the daily routine.
- mpweiher 4y agoThat's one of the reasons for agile's Working software over comprehensive documentation Working software is the common currency, we can all understand what the software looks like when it's working. (If we can't, we have whole different set of problems to solve first). It also avoids the problem Goodhart's law: when what we "measure" is the actual software to be delivered, it remains a good measure.