Seeing Like a Programmer: Resiliency, Limits, and Moral Hazards
v5.chriskrycho.com
v5.chriskrycho.com
Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.
In short engineering is the ability to follow processes and measure things. Most developers I have worked with are incapable or unwilling to measure things (on any level), therefore they are incapable or unwilling to be engineers.
If you want better software set minimal, measurable, objective standards. That becomes your foundation, your law. It is as much a soft skill as a technical skill, which is explained just before halfway through the video. Software is very very bad at this and is almost entirely reliant upon compile checks to just magically set some implicit success criteria. Most developers will balk at the idea of a disciplined planned approach and just expect some abstraction to do it for them.
Once you have achieved the process you test for compliance and you measure the result. Testing for compliance isn't a manual QA effort or tiny test units. Its a total process, a certification that you are willing to bet your job and credibility upon. For software such discipline is often foreign. In other jobs like medicine, law, law enforcement, soldiering, and even truck driving getting this horribly wrong will terminate your career forever and can land you in jail or result in devastating civil suits.
Until software is willing to become an adult like those other professions this will remain a distant challenge and its a monumental drain on the resilience of those developers who try their best to achieve that disciplined intent.
That statement may be a bit much, but working in organizations unable to, well, organize around ideas leads to the state we’re in today, where most developers has to run around like headless chickens and put out fires. There’s exceptions, but from my point of view they are pretty rare.
I've worked with what I consider to be true software engineers. They cared about the craft, about the quality of what they produced, and about the process to get there. But that team was broken up because it worked too slowly relative to less caring developers, and stuck too closely to established tech instead of shiny new things. Some of the people remained, but they were now just software developers, writing code to deliver features and meet deadlines, now counting down the days to retirement.
I've also seen quality focus conflated with architecture astronauts since both take more upfront time. When product requirements are vague, there's a tendency to design a more generalized system than strictly necessary. But not all slower speeds are for the same reason. Taking some time to think out how to meet current and immediately foreseeable needs is not the same as wasting time designing for all possibilities, but a lot of people don't seem to understand the difference. Also, sometimes you do have to go through a bit of overengineering just to learn the shape and boundaries of what you're doing.
I'll admit that companies can set up processes that encourage (or discourage) rigor, and I firmly believe you can train the yolo out of software engineers. So it's not hopeless. It is very helpful to be in a company that values these things.
Somebody has to own that. Ownership is important because that's where risk and failure live, and somebody ultimately must make the adult decisions that drives the product forward. Software leadership own the process definitions and risk acceptance while project managers own the budget and process operations.
In software this is often tiny, so its easy to gloss over and get sloppy. Consider freeway construction though which deals with a project budget that can exceed $5-20 billion, physical inventory, hundreds of people on site providing labor, and much more. There is still engineering, product delivery, a customer, and such but the liability is greater, so the planning and ownership are more disciplined. The incentives are also greater. As a result planning and modeling become more important. Injuries and defects cost money and result in halted work, so you have to account for risks and personnel in your planning. When there is no liability and limited incentives people have no real motivation to take ownership.
Other industries solve for this with some combination of licensing and broker/agent model. Licensing solves two problems. First, it sets the minimally acceptable baseline to practice and second it defines a set of ethics that become more important than employer directives.
Quoting works of Phillip Armour [0], circa 2000-2003:
... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.
... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.
... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.
------
so, IMO, it's the nature of Software (=knowledge) that spoils the (most) practitioneers - there's no gravity (or reality as such) there, so everything is (or seems) possible. And once you learn that "easy" way.. hard to unlearn.
The software as engineering discipline needs a set of substitutes for the missing nature/reality's "laws/rules". i.e. Resiliency might be one.. All the titles of the chapters of the textbooks [1] might be candidates (correctness, maintainability/ repairability, flexibility, portability, understandability, ...). And then, depending on the domain / importance, choose smaller or bigger subset, with looser or tighter conditions.
Easier to say than do it.. Most systematically-thinking people would do it implicitly - but that as well may (or will) contradict the business goals.
Just thinking aloud..
[0] http://www.amazon.com/Laws-Software-Process-Production-Manag...
You should rather consider this is a sign that software development is also partly an art, and not only an engineering discipline. Also, not all (good) developers are the same: some are more "artsy" and some are more "engineeringy".
My favorite example is accessibility, because the conformance document is so well written. Accessibility can be really challenging, but the WCAG definitions are so well written with step-by-step success criteria that accessibility can be achievable by anybody.
This is completely intractable in practice. The things that matter cannot be readily measured. Measuring a proxy to the things that matter is fraught with peril.
I’d love to see a concrete example of what you’re thinking here because in my experience it’s not possible.
This is notoriously difficult to quantify even in the simplest of examples. How do you even express goals here? What if the software is targeting a variety of platforms?
> peak memory consumption
Is this software running on a server or a users computer? What if it’s cheaper to buy more ram? How do you even measure this accurately when garbage collectors are so prevalent and there’s performance wins from using more virtual memory?
> Correct behaviour for injected faults
A standard set of faults? What about combinations of faults?
I can go on….
This technical stuff your mention can be important (I'm the first to think we should build efficient software), but are often also a small part of what matters. It might be that the vast majority of stuff that matter are not stuff you measure like this (unless you do user studies, which you should depending on the task at end). Rather, your work will be to understand what the user really needs / wants - which can be different from what they express, and it's your work to detect that), and provide a reasonable solution with potential compromises wrt means, time, budget, and what your team will like. There are few measures to do but most important decision might come from this.
If we make the users happy with this also measure-free process, the job is well done, isn't it?
Now maybe that proves a developer is mostly not an engineer and I would be okay with this actually :-)
We haven't even gotten to that level with software, forget improving people's lives.
The software equivalent of your car not exploding or your stuff falling down would be the bugs. You don't usually avoid bugs by measuring stuff, you avoid them through robust processes (including testing). I assume that's also the case for avoiding engineered things to collapse.
Now, software does often improve people's lives despite the bugs, and most bugs are not life threatening. Less reliability in software compared to many engineered stuff for cheaper production is apparently a common (and most certainly reasonable) tradeoff we are willing to make. That's not the case for software involved in critical stuff usually btw.
We haven't gotten to that level of reliability in software in general, and we probably never will, because in most cases, it's not worth the cost. It's likely not a question of rigor or maturity of the field: the human species knows how to produce reliable software when it decides it's worth the cost.
Those are not distinct categories. I was making the point that many of the things you mentioned referred to how well they improve the lives of users. These things are analogous to ergonomics, comfort, aesthetic requirements for many objects. I'm saying that those concerns come after you have built something that does not fail often.
> and most bugs are not life threatening.
Neither are most physical defects in many products, but they are still taken care of before being pushed out the door. Tesla may wish to use its users as paid beta testers, but most automakers actually test their stuff before selling it.
> Less reliability in software compared to many engineered stuff for cheaper production is apparently a common (and most certainly reasonable) tradeoff we are willing to make.
This is a tradeoff made by the companies, not be the people using it. I am forced to use Teams at work regardless of how shitty a piece of software it is. Most software companies simply don't have the kind of competition required to require them to make good software. Why spend engineering dollars on improving teams when you can bundle it and have employers force it on their employees.
* Time to build/compile
* Resource cost at execution time
* Clock time to deliver from requirements gathering to feature completion
* Developer time to complete an effort in money
* Defect quantity
* Defect severity
* Training/learning time to ramp up a new technology or feature
* Cost to produce documentation. Industry expects are amazed that the $84 million cost to produce the Air Force One documentation is actually so astonishingly low
The bottom line is that measures are a form of evidence, which is defense against arguments from bullshit. Developers typically measure absolutely nothing, so it comes to software performance developers tend to invent bullshit assumptions on the spot. They are wrong about 80% of the time and most of the time they are wrong they are wrong by several orders of magnitude.
Some measures are better than no measures, but if you don't trust the measures always gather additional evidence to disqualify them.
a quick start is setting logging level to Debug
But that would not be "agile"! Programming is mostly fashion-driven and any overlap with actual engineering is completely random.
Nope, not naive at all. Not every single thing needs to be a richly expressed type system. I actually don’t like to see a million different types for some trivial state machine. It is appropriate at times and inappropriate at other times.
Not trying to sound like a grumpy old man- but juniors read things like this and then want to make a bunch of complex types to make “errors unrepresentable” when it’s totally unnecessary and complicating in many cases.
That's in contrast to logic like:
if result.data is not None:
# Look for successful results
elif result.error is not None:
# Log or handle error
elif result.background_processing:
# Oops, optional asynchrony
else:
# Must be in-progress, right?(Or Go about 10 years ago.
I don't know if these languages got better in the meantime, I'm just reporting on my experiences from back then.)
Go is even worse.
Instead, you have object constructors. Use them.
They will dump all kinds of `if (result.is_valid)` variants over your code. But well, this is Java. It's not a different kind of shit from `if (result != null)`, and it's something you have to live with.
It's just one type, a sum type.
That being said, there’s a real tendency to take “make illegal states unrepresentable” the wrong way. I see it used as an excuse for sheer laziness, resulting in code that takes a needlessly narrow view of what constitutes valid input and handles errors in the most graceless possible way. Just because some data isn’t a valid input, doesn’t mean dropping it on the floor is always the right thing to do.
Take handling json as an example. There are at least three layers. 1. Is it syntactically valid json? 2. Is it structurally valid? Objects have the expected fields, arrays are not scalars, and so on? 3. Is it semantically valid? Numbers are within bounds, strings are not too long? For each layer, the appropriate response is different, and for each layer there’s an appropriate representation for failure. That is: failure is a legal state, and it must be representable. Confusion about this has led to some pretty poor software of late.
That’s not a million little classes, that is one class.
I listened to it this morning while doing my stoutness exercises, and there's a lot of good wisdom here. I'll probably chase down some of the books he mentions. If you're not concerned with the philosophical preamble, skip to the 5:15 mark.
brief snark: drink when he name-drops Linkedin
Re: LinkedIn—Ha! I debated on how much to include/not-include specific references to my previous employer there, and erred on the side of “let’s keep this grounded in specific real-world experience at least a little”. I think you might get mildly tipsy, but not terribly drunk.
The points about functional programming are bog standard, the characterize of "modernism" is extremely thin ("trying to master the world"?) and the connections between the two topic thinner still, if that's imaginable.
Heh, this is fair, and I actually just edited the intro in response to that feedback. In my defense, the talk itself doesn’t start that way; that was how I introduced for the folks who read my blog via feed or email subscription. Might need to iterate on having ways to add “feed-only content” for that kind of thing, because I think it’s reasonable to say that in the context of folks who already follow your work, but you’re right that it’s weird at the start of a “regular” blog post for people coming to it fresh!
Sorry to hear the rest of it didn’t land for you. Can’t win them all!
I am interested in efforts to connect the act of programming with the large issues of human existence. However, I tend to also be critical these approaches also have the danger of creating shallow, surface comparisons that don't actually provide much value.
In this case, I feel "high modernism" as a concept loses most of it's content if one removes all particular historical strands that made it. Applied in the abstract, it becomes "central control bad, M'kay".
The interesting thing is you describe a lot of programming programs reasonably but it seems obvious to me that the answer to them is ... centralization and control. The problem of many systems is that software gives the impression that everyone's needs can be accommodated simultaneously and so results in actually contradictory requirements - especially when there isn't central control of the requirements. I'm sure that could be spun as too much central control too but that spin just seems unnatural.
Now, maybe it lands that way and maybe it doesn’t, but I think that our industry could use lots of “discovering something mundane and wrapping it up as a TED talk” if it helps us to be more serious practitioners of the discipline. Most of what we need is mundane, after all! But that doesn’t mean it is unimportant, and it doesn’t mean everyone already knows it.