[HN Gopher] Professional Corner-Cutting (2016)
___________________________________________________________________
Professional Corner-Cutting (2016)
Author : MississippiGary
Score : 119 points
Date : 2024-05-12 18:55 UTC (4 hours ago)
(HTM) web link (blog.ometer.com)
(TXT) w3m dump (blog.ometer.com)
| sillysaurusx wrote:
| Am I hallucinating, or does anyone remember the Steve Jobs story
| as the exact opposite? He used backs of a cabinet as an example
| of when it's okay to cut corners, since nobody would ever see it.
| I don't remember where I heard it or what the context was, but it
| was something along the lines of him trying to get one of the
| early Mac engineers to ship faster.
|
| 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.
| jweir wrote:
| "When you're a carpenter making a beautiful chest of drawers,
| you're not going to use a piece of plywood on the back, even
| though it faces the wall and nobody will ever see it. You'll
| know it's there, so you're going to use a beautiful piece of
| wood on the back. For you to sleep well at night, the
| aesthetic, the quality, has to be carried all the way through."
| doytch wrote:
| Not only would a professional carpenter use plywood, it may
| be a sounder choice because of its stability/weight ratio.
| nextaccountic wrote:
| A plywood back would be prone to water damage, however
| mrob wrote:
| The best option is plywood for the dimensional stability,
| varnish for waterproofing, and solid wood edge trim to
| give some resilience against mechanical damage that would
| otherwise risk delamination. This also hides the ugly
| part of the plywood.
| germinator wrote:
| Yeah, it's a weird metaphor, especially since plywood is a
| premium, structural material. I _wish_ my Ikea furniture
| used plywood. Instead, you get fiberboard.
|
| 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.
| brandall10 wrote:
| The point isn't about utility, it's about aesthetics - it's
| about how the product is finished. What you use in the back
| should be the same as elsewhere.
| formerly_proven wrote:
| Even furniture from The Old Masters doesn't have
| beautiful veneered back panels, but plain, unfinished
| boards.
| sillysaurusx wrote:
| Thank you for finding the quote. I stand corrected. I think I
| misread this at the time as him saying that no one will see
| it, so it doesn't really matter. It's an interesting
| experience to wake up one day and see that the meaning of one
| of those old stories was exactly the opposite of your
| takeaway.
|
| 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.
| 6510 wrote:
| The correct answer is: I'm not, you're not either.
|
| 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.
| brandall10 wrote:
| I think that's two very different things - a complete set of
| features done poorly vs. an incomplete set of features done
| well. In general it's best to err on the side of the latter,
| it's going to give the customer a better UX.
|
| 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.
| heromal wrote:
| It didn't have 3G IIRC
| paulryanrogers wrote:
| > The other things we'd take for granted today likely weren't
| conceived then, including the App Store.
|
| IIRC, one could get apps on other platforms like Blackberry,
| even over the web. Apple's anti-innovation was a closed-
| garden storefront.
| disruptiveink wrote:
| You are correct. Steve definitely believed in doing things
| properly because you know they're there, regardless of who can
| see it: https://folklore.org/Signing_Party.html
|
| > 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.
| tejtm wrote:
| That was done in Amiga 1000 cases 1985-ish. I would be
| surpised if they were the first.
|
| https://www.commodore-
| info.com/computer/item/a1000/en/deskto...
| ricardobeat wrote:
| The parent folklore.org link mentions this happened at
| Apple in 1982, end of first paragraph.
| tejtm wrote:
| And, Jobs visited Amiga in 1983 which also suggests the
| idea came from him.
| rmnwski wrote:
| I think you got it wrong. That's why the motherboards on macs
| for example are "beautiful" and black.
| iwontberude wrote:
| A cabinetmaker creates the polished front and the unfinished
| rear. A software/hardware company needs everyone being part
| of the polished front at least in spirit. I liken it to
| people dressing for their job.
| c22 wrote:
| I haven't used an Apple product in some time, but to me it
| always felt like their software was the unfinished rear.
| fifteen1506 wrote:
| TL;DR.
|
| Cutting corners sometimes makes sense -- that's why timeboxing is
| important. But always?
| ungreased0675 wrote:
| I like the last paragraph. Will remember that when an engineer
| slows down a project talking about code smells and revisiting
| architecture decisions.
|
| > Professional software developers are performing a service for
| others. That's the difference between a professional and a
| hobbyist or an artist.
| OtherShrezzing wrote:
| I'd probably drop the "or an artist" in the retelling though.
| Lots of artists are definitionally performing for others.
| dt3ft wrote:
| > code smells and revisiting architecture decisions
|
| 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.
| ungreased0675 wrote:
| You're correct, I was thinking of a specific software
| architect when I wrote that.
| fuzzy2 wrote:
| Why blame anyone at all? Did everyone work to the best of
| their knowledge and beliefs? If not, why? And if they did,
| how are they to blame?
|
| 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.
| bojan wrote:
| There is certainly a a balance to be struck. Are the code
| smells a structural issue in a piece of software that's
| supposed to be used and modified for a long time? Then those
| code smells endanger delivering the service in a medium term
| and should be addressed.
|
| 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.
| baobabKoodaa wrote:
| There are people working in software who will _always_ want
| to refactor something into "clean code", no matter how many
| times it has been done before. It's just never going to reach
| a point where that person says "I'm happy with it, let's get
| back to building features". If you want to build features (at
| all!) then you have to sometimes tell that person "no, we're
| not refactoring this again".
| Havoc wrote:
| Found this particularly tricky with hobby projects around cost. I
| can spend a bit more time on clever engineering to fit it into
| free tier but that saves me what. Price of a coffee? For loads of
| extra complexity and time
| ilaksh wrote:
| Oftentimes managers will make demands that interfere with
| ownership of the code. Such as requiring something to be finished
| in half the time it would take to do it without technical debt.
| Over and over and over again.
|
| 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.
| justin_oaks wrote:
| A cabinet maker has the option to say no because they're the
| one in charge of accepting the job AND implementing it. At
| least that's the way the article made it sound.
|
| 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?
| jbmsf wrote:
| Our profession doesn't always work the way you describe. Some
| companies want cogs, some want professionals.
|
| 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.
| RangerScience wrote:
| Yah. Article's advice about "owning the implementation" is
| great and all, but limited to places where you're not blocked
| from or fired for doing it.
|
| 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.
| willcipriano wrote:
| Advise them of the issue. If they still want it, their funeral.
|
| Anytime I move away from this frame it's not worked out for me.
| skydhash wrote:
| More often than not, you have n > 1 implementation solutions
| possibles. The article said to factor the constraints into the
| choice of solutions, not the solution itself.
|
| 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.
| justin_oaks wrote:
| > If the technical debt is a problem, 1) we shouldn't have put it
| in there, and 2) we should include it in our estimates and
| address it.
|
| 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.
| RangerScience wrote:
| You know I wonder... why do so many of us feel like we need our
| boss to understand?
| hobs wrote:
| Because the boss says they want to understand, drags you to
| endless meetings to understand, but then manages to makes
| arbitrary decisions based on none of that information.
| rapfaria wrote:
| Perhaps it's not a close relationship. Perhaps the boss is
| insecure about his management skills and has to constantly
| check on the team, to make sure every variable is under his
| radar.
| onion2k wrote:
| Most of us work in organizations where the boss is a former
| engineer who understands the problem of tech debt perfectly
| well. If your boss is a former dev and they aren't taking it
| seriously the problem is usually that they're a bit too keen
| to say yes to other parts of the business.
| YZF wrote:
| This is not the right answer for a real business. Sometimes
| we'll fix that later is perfectly acceptable. If that was good
| enough for Facebook it can certainly be good enough for others.
| speed_spread wrote:
| Its up to the engineers to factor in maintenance work as part
| of their estimates. Business people assume perfect software
| and react badly when confronted with the messiness of
| software development.
|
| Also, Facebook being a real business is questionable.
| YZF wrote:
| Meta's market cap is 1.2T, it has $60B cash, revenue 143B a
| quarter... Not a real business? I mean maybe the original
| team in FB should have made sure they didn't accumulate
| technical debt and FB having failed would be a better
| outcome for shareholders.
|
| 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.
| dkarl wrote:
| The hook of the article leaves unanswered the question of _why_
| Steve Jobs made a big deal out of the backs of cabinets. The
| answer is that Steve Jobs knew how to sell luxury items to people
| who identified themselves with the quality of their work, whether
| they were accomplished creative professionals or cube-dwelling
| (now coworking) "knowledge workers" or MBAs who take sommelier
| classes or aspiring writers grinding on their novels at
| Starbucks. It was partly about the experience of using an Apple
| product, but it was just as much, if not more, about vicariously
| identifying with the standards of craftsmanship. If it was only
| about the experience, and the craftsmanship was a means to the
| experience, then the backs of the cabinets would not have
| mattered. They mattered because the craftsmanship was not just a
| means but was fetishized for its own sake.
| gofreddygo wrote:
| Article is spot about its topic - tradeoffs. The
| professionalism is in picking the right corners to cut.
|
| 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.
| empiko wrote:
| It is not about the backs of cabinets. It is about telling your
| customers how big of a deal the backs of cabinets really are.
| nebula8804 wrote:
| The back of Apple cabinets are are actually pretty good even
| in the Tim Cook era.
|
| [1]: https://www.cultofmac.com/320883/why-samsungs-design-
| sucks-i...
|
| [2]: https://ioshacker.com/iphone/image-compares-ugly-
| samsung-bea...
| makeitdouble wrote:
| It's in the link on the relevant bit [0]. TLDR: his dad built
| stuff, including as a hobby, and he liked overengineering. He
| liked he dad very much and also got on board with
| overengineering.
|
| [0] http://thenextweb.com/apple/2011/10/24/steve-jobs-
| obsession-...
| renewiltord wrote:
| "Any fool can build a bridge that stands. It takes an engineer to
| build a bridge that barely stands".
|
| Absent trade-offs I can do anything.
| maerF0x0 wrote:
| or as I like to tell my product folks "I can build you anything
| a computer can do, but you might not like the cost"
| jack_h wrote:
| I'm going to have to disagree with the entire premise of this
| piece.
|
| 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.
| skydhash wrote:
| What I've seen mostly is developers bringing complexity, then
| cutting corners after that because they don't want to deal with
| it. In _Coders at work_ , Douglas Crockford said to spend the
| sixth cycle - whatever the cycle is - on refactoring. It's a
| sound advice if you care about technical debt as an engineer.
| Spend some time to revisit the code architecture to see if it
| still fits the problem you're solving. Instead of spending
| three cycles on something that could have been done in one
| because of how fragile everything is. Or having a long list
| that is tied to the same root cause.
|
| Sometimes it means redo your React marketing website in Node
| and EJS (or the equivalent) instead of trying to make it SSR
| too.
| jack_h wrote:
| > In Coders at work, Douglas Crockford said to spend the
| sixth cycle - whatever the cycle is - on refactoring. It's a
| sound advice if you care about technical debt as an engineer.
|
| 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.
| yakkomajuri wrote:
| In a lot of organizations I feel like #2 is often the difficulty.
| However, interestingly there is an opposite phenomenon where
| people are too focused on #2 (understanding customer needs) and
| thus fail at #1 (owning implementation).
|
| 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.
| Vinnl wrote:
| One of my frustrations is how people often seem to drift towards
| one of the extremes on either side of this argument. Technically,
| the approach described in this article is called 'pragmatism',
| but in practice, people have used that term to describe the bad
| kind of corner cutting.
|
| 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.
| maerF0x0 wrote:
| > A professional developer does thorough work when it matters,
| and cuts irrelevant corners that aren't worth wasting time on.
| Extremely productive developers don't have supernatural coding
| skills; their secret is to write only the code that matters.
|
| 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.
| arnorhs wrote:
| This is ambiguously stepping into "overly general / building
| for the future" territory. Perhaps that is not what you meant.
|
| 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..
| jxl62 wrote:
| The ideas aren't as universal as they are made out to be.
| "Technical tradeoffs" are often not just technical, but also a
| business decision. They can have significantly different risks,
| costs and implications for business strategy. You may not have
| the insight into these things like someone who makes it their
| job. The "tenons" comparison frames these decisions as being
| trivial details that happen in a vaccum which smells like
| strawman. There are generally more factors to consider in tech
| decisions, and unlike cabinetry there is often a great deal of
| uncertainty in how it will play out in the future. This advice
| could be reasonable in the right company and role, while
| completely setting someone up for failure in another. There's
| irony in the article being about corner cutting and tunnel
| vision.
| afro88 wrote:
| > If the technical debt is a problem, 1) we shouldn't have put it
| in there
|
| 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.
| skydhash wrote:
| > 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
|
| 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.
| afro88 wrote:
| You do need to understand the pros and cons, and wow there
| are some incredible time and complexity costs to maintaining
| all dependencies yourself, or trying to firewall all
| dependencies through interfaces.
|
| 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.
| advael wrote:
| I agree with everything in this article. However, software
| developers may be craftspeople, but an infinitessimally small
| fraction of them are treated like craftspeople by the businesses
| that employ them
|
| 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
| brudgers wrote:
| _Cabinetmakers were focused on what their customers cared about._
|
| 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.
| JadeNB wrote:
| > A professional developer does thorough work when it matters,
| and cuts irrelevant corners that aren't worth wasting time on.
|
| 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?
| wly_cdgr wrote:
| There's a reason everyone knows who Steve Jobs is and no one
| knows or cares who the vast majority of these corner-cutting
| "professionals" are
| bee_rider wrote:
| I don't think software is like a cabinet at all. A cabinet is a
| well-understood thing, the main job of the cabinet craftsman is
| to implement the existing cabinet idea.
|
| 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.
___________________________________________________________________
(page generated 2024-05-12 23:00 UTC)