Professional Corner-Cutting (2016)
blog.ometer.com
blog.ometer.com
Steve's marketing was IMO a whole load of bollocks, like all other marketing. it gets attention now when Apple is a trillion $$$ company, and superficial minds wanting a simple answer attribute it to the most visible thing - Apple's marketing. no one bought Apple products for Apple's marketing or advertising. Its for the weirdos. Same theme as other Apple marketing e.g. the bicycle for the mind metaphor, the 1984 ad, etc.
This article is good and its not about the backs of cabinets.
That statement would require quite a source. Of course a lot of people bought Apple products because of the ads, like for any company that is a serious advertiser.
Apple revenue not so great till 2000s [2]
What changed ?
[1]: https://www.macworld.com/article/670956/the-14-best-apple-ad...
[2]: https://www.statista.com/chart/4574/apples-revenue-since-197...
[1]: https://www.cultofmac.com/320883/why-samsungs-design-sucks-i...
[2]: https://ioshacker.com/iphone/image-compares-ugly-samsung-bea...
The second… more like the back of the cabinet maybe. Although the better style there might also be somewhat functional; the internals are clearly quite different, one could imagine that the nice packaging in the Apple case might be a result of only wanting people to use approved parts.
The metaphor seemed to have gone over your head.
>The second… more like the back of the cabinet maybe. Although the better style there might also be somewhat functional; the internals are clearly quite different, one could imagine that the nice packaging in the Apple case might be a result of only wanting people to use approved parts.
This philosophy applies to their entire product line and has essentially been the case since Jobs came back. Hell looking at the first 1984 Mac this philosophy was there.
Apple never really cared for ports practicality, we've had the same discussion with the finewoven cases that wouldn't allow for regular thickness usb-c cables. Other makers made more of an effort on that front.
The second would be a better point if iPhone's repairability was on par with Samsung's. Granted Samsung also became worse with time, but it was in no small part because of what the market leader could get away with.
That said, I think your general point stabds: Apple cares about the back of the drawer. But not in the way I personally wish they cared.
That is shown in the first link but only if you scroll down to the second photo.
Also TIL Iphones have two separate batteries? Quite unusual.
[0] http://thenextweb.com/apple/2011/10/24/steve-jobs-obsession-...
Perhaps Steve Jobs wasn't an expert in engineering so he didn't know which corners to cut and therefore avoided cutting any corners out of fear of cutting the wrong one?
Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later."
Later never happens and eliminating related technical debt is part of implementing the feature.
Don't ask your boss about this stuff. It's part of your job and it's something you understand that your boss probably doesn't.
If they don’t understand what we’re doing or why things take as long as they do, that’s bad for us.
Also, Facebook being a real business is questionable.
Engineers need to give the business the options. Not unilaterally decide that they're not going to accumulate technical debt. That's my point.
And trust me, business people don't assume perfect software (at least if they've been in business for any amount of time). [EDIT: What's maybe different about] business people is they a) look at things as a negotiation. b) want to get the max value for their investment c) likely have seen a lot of engineering projects from the outside. Engineering needs to work with the business not go and decide what's right for the business. This doesn't mean you don't have ethical responsibilities as a software engineer in many situations but there are also many situations where the business needs to call the right balance between engineering effort the things like quality or feature sets.
https://www.ieee.org/about/corporate/governance/p7-8.html
Would seem to preclude working on a site, like Facebook
> 1. to hold paramount the safety, health, and welfare of the public, to strive to comply with ethical design and sustainable development practices, to protect the privacy of others, and to disclose promptly factors that might endanger the public or the environment;
Given that sites like Facebook have been used to spread medical conspiracy theories (health of the public), the whole business model is privacy violations, and the site was used to enable the Rohingya massacre (safety/welfare of the public),
https://www.pbs.org/newshour/amp/world/amnesty-report-finds-...
But I mean an ethical engineer wouldn’t get in the way of a place like Facebook because they wouldn’t work there in the first place.
I would interpret IEEE's statement as it affects a single engineer to e.g. ensure that they are following best practices in protecting user information, e.g. if an engineer is asked by Meta to take some shortcut that exposes people's information publicly that would grounds for refusing to do that on an ethical basis.
That said as an individual you ofcourse have a choice where you want to work. I can see someone not wanting to work for Meta. I'm sure there are many ways in which Meta also supports safety and health, e.g. some (a lot) of useful and good information is also available on the platform. We should look at the totality of the company's impact, not just one aspect of it. That said I agree that hate amplification and disinformation on the Internet is of concern. It should be up to governments to take action on that. I think with Meta and other Internet companies they have immunity in the US for being sued over content others publish on their platforms.
Ethics are self-enforced mostly, and they are to be followed in good faith. An ethical engineer should not break the law, but nobody should break the law, that’s the bare minimum for existing in society.
If you thought the internet was overwhelmingly harmful and had little-to-no redeeming value, yes, working on network switches would be unethical.
> I would interpret IEEE's statement as it affects a single engineer to e.g. ensure that they are following best practices in protecting user information, e.g. if an engineer is asked by Meta to take some shortcut that exposes people's information publicly that would grounds for refusing to do that on an ethical basis.
I don’t see any particular reason to think they just mean exposing personal information to the public, when they talk about protecting privacy. I’d tend to assume Meta, like every other entity, is something we ought to protect people’s privacy from.
It is up to you to interpret the meaning personally. But nobody is going to punish you if you don’t obey the code, so why look for an out? Just don’t follow it.
But sometimes your product is so buggy nobody wants to use it. It's all trade-offs, just like… well, engineering.
We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between.
The biggest problem is that bosses aren't in a good position to understand the code you're looking at. So if you're a professional, you'll make the call as to whether or not some tech debt is worth fixing now or not.
The boss's job is to communicate the urgency and importance of your task, how it fits in with the company's goals, etc. Your job is to carry out the task with a reasonably balanced ratio of quality to time.
I feel like a lot of conversations around technical debt miss this nuance.
There are plenty of systems I’ve worked on that have been either (1) running for years without issue or (2) deprecated and deleted without ever addressing most of the “debt” issues/tickets that my team and I created in our tracking systems.
I think a lot of engineers take pride in their craft (which is good). Until you learn that a cabinet with a rough back is still a great cabinet, you’re doomed to feel uneasy about leaving something “unfinished”. So many people feel they left some “hack” in the code they want to fix. Which is different than a bug. There are endless improvements possible. YAGNI.
Something that will inevitably cause serious trouble down the road doesn't have to be fixed immediately. It can be fixed later. The proper decision for the business is whether the "interest" on waiting is worth it. There are many examples of this in the real world. It's simply not true that "fix later" is always a lie. What's more likely to be the case is that as new requirements are discovered there will be churn and it'll turn out it wasn't actually worth fixing this thing that you thought would cause serious trouble "down the road".
I'm a "boss" and I'm a software engineer. My bosses are also software people. My CEO is a software engineer. What I expect my team to do is to give me the tradeoffs. What I don't want them to do is make business calls. If we lose a huge business opportunity because we can't make a milestone with a customer because an engineer made a decision on his own to spend weeks dealing with some corner case and the whole company goes down the drain that engineer is not professional.
Again we're not talking about situations where this would be unethical, we're talking about a tradeoff a business makes to go forward with certain limitations of some software in order to meet some business goal.
It's a struggle to come up with a better name, though.
The practical definition is clear. It's a lack of maintenence of core abstraction. Leftovers from different designs, deeply embedded into our solution. Sometimes we plan for it to live in a corner somewhere, but more often we discover the failure of some abstraction all too late.
It doesn't work like debt at all. We didn't sign a termsheet, and we didn't calculate the impact. We need to move beyond this hopeless metaphor such that we can actually discuss what software needs, because right we're staring at a field emptied of nitrogen by years of farming and saying it has a "resource debt"
Which is very much like going to the bank and trusting it that it's going to be ok without looking at numbers; or going to a mob shark for a loan, but it's actually Darth Vader and he'll make sure to alter the deal any way he sees fit.
Evaluating what tech debt is going to cost (through coupling and accidental complexity) is definitely part of the job. That responsible engineers yelling it's going to cost a lot are then ignored is part of the systemic cultural problem.
Let me give a somewhat concrete example. Someone from business came to me to ask how hard it would be to fix a bug. It wasn't super urgent. The user experience of the bug wasn't too bad, a minor annoyance. But it seemed like such a small thing that they thought the fix couldn't take more than a few days. When I informed them it would take weeks at a minimum and more likely months, they were very confused, until I explained that a design made in the early days of the company (before I worked there) made this particular bug extremely difficult to fix. We would either have to redesign an entire system in a more robust way, or work around the limitations of the current system which would be faster, but still much more difficult than ot should be. And doing so wouldn't help at all with fixing the myriad other problems caused by this design choice.
And although I wasn't involved in the original design, I think at the time it wasn't a terrible decision. It allowed the company to get something out that worked pretty well, and helped the company grow quickly. But now that technical debt was slowing down other development.
The answer to that answer is more questions:
- how will we fix it, properly, later when we can't fix it now? Won't there be more features to be done later?
- what if we fix it later and it creates its own issues and then someone will ask why did we touch it when it was working? If it breaks now, we can fix those breakages because we are already touching it.
- if later, as part of which release?
Don't actually ask these questions - they will piss-off your boss even more.
And whenever you're arguing against someone drifting too far to one of the extremes, you'll often get lumped in with those on the other: to a perfectionist, you'll be considered a lazy, sloppy worker, whereas the corner-cutter will consider you to be super pedantic and not the type to 'get things done'.
On the other hand, when you do get to have a proper discussion on whether a corner is worth cutting — i.e. if it will actually affect the user's experience — and you end up being able to save time without materially affecting the end product or future maintenance work, that is enormously enjoyable.
There is absolutely a place for the kind of craftsmenship your are describing, but if you don’t understand the incentives of your workplace you are in for heartache.
I have had a lot of clients like this. It's very common especially for lower budget projects. You can literally cut corners you don't really want to or just get replaced by someone who does.
They will often also insist on certain technical decisions like choice of programming language or framework.
Most of us are cogs in the machine and are given much less autonomy.
So what is the "professional" to do if given a job and insufficient time to do it?
I can't give you advice beyond that, there are too many different circumstances. But in most of the places I've worked, it's been developers, not managers, cutting corners. Sometimes these are good choices, informed by product context and trade-offs. Sometimes it's a perceived urgency that doesn't actually exist. But it's almost never a micromanaging boss asking for something specific.
They don’t ask people to cut corners specifically, they just create a culture where speed is paramount above all else. Where the only metric of success is tickets completed per day.
This doesn't mean that there's never a need to hurry, external deadlines exist, but these are the minority in a healthy organization.
Notably, from my small sample size (only small startups) - I don’t think I’ve known anyone who was fired for doing it. So it seems like it’s not a thing we can do… but I bet it’s something we can do in a lot more situations than we think.
Anytime I move away from this frame it's not worked out for me.
Like if it would take 6 months to implement a backend, but just 1 month with Firebase, and time is a more important than data ownership, you go with Firebase. Then you prepare a plan if you ever need to migrate off Firebase. If you don't have time to do a custom UI, you go with a components library. That also means knowing the range of possible solutions (aka mastery). If nothing else, you reduce scope.
There's a plethora of ways to respect time/monetary constraints without resorting to shoddy code and duck taping.
Perfectionism to an expert often means the opposite. The difference is the expert knows what is worth time and effort.
Somewhere in the learning process, a beginner must intermediate, and then become an expert.
The reason software engineers want to push decisions to their managers is that their managers believe in nonsense like slicing up tasks into their tiniest constituent parts and meticulously estimating how much time they will take. Practices like lean and scrum and kanban are managerial conventional wisdom about how to manage a factory, not craftsperson conventional wisdom about how to make good things efficiently
As long as the people running the show are going to hold their people responsible to fiddly metrics and demand to know every detail of decisions that affect how their software people are spending their time, they will act according to those incentives, avoid making decisions where possible, quibble about every little detail
Software should be a craft. Treating it that way produces better software. In order to foment a mindset of a craftsperson, you must treat them with the trust and respect that we give to craftspeople. Most modern humans don't even have a script for interacting with craftspeople these days, and business jocks drunk on rebranded Taylorism certainly don't apply one when managing people they view as a means to better valuation
IMO the true mark of a professional, a truly talented, engineer is knowing which corners to round off before they cut you. Anyone can cut corners and leave the world full of problems for the next guy. But then the assumptions change. A queue gets really full, or we start needing utf-8 for emojis, or someone wants to rearrage the field order in a CSV.
A great engineer would make a system that just works in those cases, because they can be (at least in go, node, python) implemented in just as many lines, just as complex of code, the only thing required is foresight (or its cousin, experience). Many will say YAGNI, but in my experience these things almost always come up (and I'm sure there are many others). Sometimes being a great engineer means reading between the lines of product designs, past sevs, and experience to figure out what the real feature ought to be.
There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner.
Examples such as that do come to mind. But as I said it's a fine line.
This becomes exceptionally tricky when you are building towards a vision, but only 40% there, and having the code structured for that vision is hard to shake..
I struggle with making that trade-off in terms of what's worth pointing out. Often what I'll do is point it out, but with an explicit disclaimer that I'm mostly pointing it out because it's good to know for the future, but that it's not a blocker (for larger chunks of work).
There was a lot of corner cutting to get the original iPhone launched. They barely made it in time. The parts that mattered were polished to perfection, but you wouldn’t want to use an iPhone 1 today — all the other parts you take for granted now would be painfully visible then.
It's also a good example of how the metaphor this blog post is predicated on can fall apart. Your customers care about durability, but they make purchasing decisions based on cost and outward appearance. In a world like that, where you can't satisfy all requirements at once, you inevitably end up cutting corners on the things the customer cares about but can't measure. But is that right? That's how you end up with $200 furniture that lasts a year or two in a home with children or pets.
It's also easy to neglect cumulative costs. Back to software: does it matter if your app uses 100 MB of memory when it could be using 1 MB? On an individual basis, no, because RAM is cheap. Cumulatively, when every other app developer thinks the same, and when you multiply it by billions of devices, your decision might have actually cost lives if you consider the increased emissions and countless other distant externalities.
A milder version of the blog's claim is definitely true. You should pick your battles. But it's all about trade-offs, there are few problems that truly don't matter to anyone.
In hindsight there does seem to be some truth to this. What surprised me about the Hacker News codebase is that pg almost never cut corners. To this day I still find new features I never realized I wanted. On the other hand, pg never coded anything unless it was absolutely necessary for whatever he was trying to accomplish (or at least he presented his few public pieces of code as such), which is something I’ve had trouble emulating. Coding is just too much fun sometimes.
I've oddly asked a carpenter why he was using plywood, his response was: I'd prefer not to but this is what people want nowadays. (meaning this specific customer)
If you are a software engineer you, with pride, rewrite half the company in rust and the other half in elixer. Tell the board you wont be able to sleep.
What exactly was the original iPhone missing? The only thing in the OS I recall was copy/paste. The other things we'd take for granted today likely weren't conceived then, including the App Store. The main issues was that it was a frustratingly slow experience, so OS/proc performance, and EDGE which was the best widely available at the time was insufficient.
IIRC, one could get apps on other platforms like Blackberry, even over the web. Apple's anti-innovation was a closed-garden storefront.
> Steve came up with the awesome idea of having each team member's signature engraved on the hard tool that molded the plastic case, so our signatures would appear inside the case of every Mac that rolled off the production line. Most customers would never see them, since you needed a special tool to look inside, but we would take pride in knowing that our names were in there, even if no one else knew.
https://www.commodore-info.com/computer/item/a1000/en/deskto...
You see it an awful lot with internet routers lol.
Cabinet makers don’t do sprints because everybody knows what a cabinet is, there isn’t any need to aggressively iterate on the design.
The software equivalent to buying cabinets is buying existing software. You don’t employ a bunch of engineers to install cabinets.
If you went into workshop with a bunch of mechanical engineers and asked “I need you to reinvent the idea of holding plates,” that might take some sprints. It would be a silly thing to do, but it would make the analogy fit.
Absent trade-offs I can do anything.
> Professional software developers are performing a service for others. That’s the difference between a professional and a hobbyist or an artist.
This is exactly what we're dealing with on top of shipping new features. An architectural decision that got changed 6 months later so the code had to be thrown out and re-written.
Don't blame the engineers, blame the architects. If you have any.
I make incorrect decisions all the time. I will continue to make them. Because I do not shy from making decisions and neither should anyone else.
But are we talking about a one-time migration script or a fad mobile app? Then who cares, the service will be delivered regardless of the quality of the code.
More likely, they focused on what their customers would pay for. People with Steve Jobs money might be willing to pay a premium for finished cabinet backs.
Most people don’t have Steve Jobs money. But people without Steve Jobs money are no more or less likely to appreciate finished cabinet backs than people with Steve Jobs money…it’s not hard to imagine Charlie Munger having a mid-western view on finished cabinet backs.
Since end users usually don’t see any more or less of steaming turd code than well structured code, there must be something besides “cabinet making” at work. My gut is that strong opinions about code are a way to make the banality of code writing interesting. Strong opinions add melodrama to the mundane work that doesn’t matter much beyond the paycheck that comes with it we all must do.
Getting paid is the meaningful metric of professionalism.
I guess it depends on your definition of tech debt, but there are lots of examples of things that aren't tech debt at the time but become tech debt over time. You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency you needed to upgrade, and you need a few days to figure it out.
A cabinet maker might not put "make tenons straight" in a sprint, they would include it in the estimate and not tell the customer, sure. But they would definitely tell the customer that their lathe tool broke and they needed a few days for repair before continuing work.
This is a solved problem. You either understand the dependency enough to maintain it yourself, or you firewall it through interfaces. Or you tie yourself to sensible projects that gives you time for upgrade. Or you pay for support. Every decision should be taken with a complete understanding of pros and cons, and risk management to reduce the latter.
This cabinet make should either have a backup tool or be confident they can do the repair in a way that doesn't impact their consumer.
I wasn't talking about blindly doing stuff without understanding consequences and risk managing. I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today.
Firewalling all interfaces to dependencies for example can be future tech debt if you need to move fast to stay ahead of competitors, but all the indirection is making development too slow (or causing developers to find other more enjoyable work). Can't imagine working on a React codebase where React is completely abstracted behind our own interfaces to all of it.
I agree
> wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces.
I'm not saying you should firewall everything. But if it make sense, you do so. You also need someones that understand each core deps enough they can patch it if the maintainers won't resolve an issue (happens more in the npm world). Even with React, you can extract the business logic and reuse it elsewhere. The goal is to avoid depending that much on projects that have less stability than yours (some bad experiences here with React Native). How you do it is contextual, but you should keep it in mind.
I've seen it happen where non-technical users of internal tools request very specific features that get built just because and at whatever cost without the team asking what is the actual problem this feature solves and how can we best build something to address the problem given our knowledge of the technical side. It's often requests for tools that allow people to do things manually when the team should just spend some time automating away the need to manual intervention.
The problem, it seems to me, is that, while a furniture maker may have a reasonably stable idea of what their furniture will be used for, I think the makers of truly useful software can have no reasonable idea of the uses to which their software will eventually be put, and so must design so that the program can accommodate the demands put on it, no matter how unexpected or bizarre. How many modern security issues (I ask rhetorically) stem from design decisions rooted, explicitly or implicitly, in the assumption that the software would never be exposed to hostile actors?
The entire Craftsman movement under Raskin, Morris etc. started up because of the move of craftsmen into factories, where they worked on parts of the whole and could therefore not be craftsmen anymore.
Exactly what I think of when I read this.
I think the most pertinent question here is: whose time?
If you are a cabinet maker you have many individual clients who all want what you're producing. They each have their own budget and preferences that you can work with to get them something they want to buy. The incentives and constraints are clear here. If you can make something the client wants at a price and quality point they can afford you will do well.
Many (most?) software developers create a product to satisfy the needs of many customers and non-customers simultaneously. Furthermore you almost never interact directly with customers; instead developers interact with a panoply of different business interests such as engineering managers, product managers, project manager, product owners, etc. Even worse software doesn't have to be done to ship it as it can always be fixed "later". With the advent of Agile, Scrum, and SAFe it's clear what the business wants is not someone good at a craft; they want an assembly line.
So what are the incentive structures and constraints here? Every other person has incentives for career advancement, bonuses, raises, etc. Most people are too far removed from customers to be directly affected by them. How many times has a cabinet maker been told that the hope chest they're working on for one client also needs to double as a bank vault. Oh and by the way it needs to be done by the end of the quarter (right after layoffs of course) because they are hoping to be bought out. Code bases end up being a fractured mess of bad abstractions, infinite abstractions, and rewrites because developers are trying to accommodate the impossible demands set forth by the business in a way that doesn't cause their job to be abject misery.
TLDR: most software developers are not expected to be craftsmen (or women). The company determines, through incentives and constraints, the quality of code it will produce. An individual software developer risks burnout if they think quality above and beyond what the company allows is within their responsibilities or capabilities.
Sometimes it means redo your React marketing website in Node and EJS (or the equivalent) instead of trying to make it SSR too.
My point is that very often it's not up to engineers. If a company doesn't incentivize this refactoring and engineers have to - as some sibling comments suggest - inflate their estimates then the code base will deteriorate over time. Even if your team sets up a policy of doing refactoring ~15% of the time this will be overridden by business interests more often than not.
This is essentially a corollary of Conway's Law. You should not expect code bases to be better than the business incentivizes it to be. I'm speaking from personal experience here; this is burnout territory. Keep in mind these are very general observations and every company is different. In some companies what you and Crockford suggest is possible. I'd wager it's the exception rather than the rule though.
Cutting corners sometimes makes sense -- that's why timeboxing is important. But always?