[HN Gopher] Imaginary problems are the root of bad software
___________________________________________________________________
Imaginary problems are the root of bad software
Author : deofoo
Score : 500 points
Date : 2023-06-18 14:42 UTC (8 hours ago)
(HTM) web link (cerebralab.com)
(TXT) w3m dump (cerebralab.com)
| avgcorrection wrote:
| I gave up on this article when I found out that the first
| hypothetical scenario has no relation to reality.
|
| Implementing something else "because if they implemented the real
| spec they would get bored" is too much psychology.
| legulere wrote:
| The article rests on the idea that the management knows what
| needs to get built, but my experience so far was that they are
| usually even worse at that.
| danielovichdk wrote:
| I dont want to get paid and have fun.
|
| I want to get paid to solve real fucking problems which has a
| factual validated need from real people.
|
| Most people are terrible professionals. Writes code to have fun
| and expects to be paid too. And even blogs about it too.
|
| I want to be in the trenches. Hard work. Real work. Not some
| glamorous bullshit that lasts nowhere. Quality long lived
| treasure is what I strive for.
|
| And I dont want to progress by applying popculture technologies
| because some punks subjective opinion wants to have fun. One has
| to be a prick and tell these people off because they shovel shit
| and pad their own backs when the re-shovels it with a new fad.
|
| I want to progress by making slow surgery like precision work. I
| want to make sure that what I do sticks and is sound quality, no
| code is written for fun. Code is a fucking liability.
|
| Between the scams and the hustle, the number runners and the pick
| pockets, real people with real quality minds do real good work.
| Those are the only programmers worth being around and hire.
| Everything else is just a waste of time and mental capacity.
|
| So many morons in this business. It's really too much.
| hinkley wrote:
| I spend a lot of time saying "I told you so" to people who were
| sure my problems were imaginary. When you don't stay somewhere
| long or you have a short time horizon it's hard to connect cause
| and effect. Also pretending uncomfortable things don't exist is a
| very popular character trait.
|
| It's not impossible that some of the problems I see others
| manufacture have a genesis in past traumas they are trying to
| avoid (some coping mechanisms are healthier than others).
| arpinum wrote:
| Author gets it half right. Too many developers trying to have fun
| by doing new things. Affordable initial software development
| tends to come from places that have boring templated solutions
| using 1-2 tools.
|
| But the main argument is off - What some classify as imaginary
| problems is actually building in the wrong types of affordances.
| The only way to know the difference is by knowing your tools and
| the problem domain.
|
| The root of bad software is leaders lacking practiced learning.
| daguar wrote:
| This is why I truly love support-driven development.
|
| While it's possible to prioritize problems that don't affect most
| people (squeaky wheels) it's a hell of a lot more effective than
| most of the methods I know to have a very low barrier to
| contacting you for users, and fixing the things that come up.
| vinyl7 wrote:
| Developers have a lot in common with Rube Goldberg
| HellDunkel wrote:
| In the imaginary case of the merch selling android app i dont
| think it is justified to solely blame the developers for the bad
| product. The root cause for a bad outcome lies in the simple fact
| that nobody wanted to tell the client that there was already a
| solution for 20 bucks and absolutely no need for something custom
| built. NOBODY except the business owner gains anything in this
| and the client deserves the ripoff too. It comes as no surprise
| that developers look for interesting challenges without appearing
| too distracted by the stupid and boring bs work they are stuck
| with.
| golergka wrote:
| Good reputation?
| HellDunkel wrote:
| Pure luxury if you live from hand to mouth.
| Wowfunhappy wrote:
| Reputation is what gets you more business in the future.
| You can expand your business or raise rates, or both.
|
| Yes, this won't help if you're literally in danger of not
| meeting payroll next week, but I would hope most businesses
| don't operate so close to the edge.
| t43562 wrote:
| On one project I did it was essential to be able to record how
| much a tool was used so that we could charge for it. The tool ran
| locally on the customers' machine and reported to our service.
| The overall mechanism that sent and received this information had
| to be reliable or we'd lose money but even worse would be to in
| some way overcharge customers. Lots of aspects of the design were
| complicated by this concern.
|
| Then we ended up deciding not to make money out of it that way.
| So we burned enormous effort and created a horrible design for no
| reason.
|
| So IMO the problem is usually with the way requirements are not
| usually well understood even by the people asking for them. Later
| on it becomes clearer what is needed but you're stuck with false
| assumptions baked into your design in a way that you never have
| bandwidth to remove because you need so much bandwidth just to do
| normal work....because of those assumptions.
| drc500free wrote:
| I think the most important function of a good Product
| Management team is to understand what parts of the go-to-market
| impact tech decisions and spend 80% of their energy into
| pinning those down as firmly as possible. There is a happy
| medium between JIT delivery of specs for random features and a
| hard two-year roadmap that can't react to business changes.
|
| YNGNA is generally true, but Product's should have a very clear
| vision of what kinds of entities the system is going to handle
| over then next 36 months before they start asking for specific
| functionality. I've seen extra shit get built, but I've also
| seen e.g. a travel booking system that was built without a
| "flight" being a first class entity. Flights were deduced on
| the front end from attributes attached to seats... which worked
| well until a PM asked for the UI to show fully-booked flights,
| which HAVE no available seats that make it to the front end.
| Same product couldn't handle the booker and traveler being
| different people, when they knew from day 1 that it would be a
| necessary feature. It would have been little extra work to
| incorporate into the data model from the beginning, even if the
| two values were always the same for a while.
|
| I think the majority of the technical debt I've seen that isn't
| ci/cd related is disconnect between the domain model the
| product team is working in and the data model the engineering
| team is working with. Formalizing that domain model is now one
| of the first things I do when joining a team, so everyone
| agrees on precisely what the major nouns and verbs are and how
| they interact. Not just for the current system, for where we
| think we will be in 2-3 years. With everyone doing agile, it's
| amazing how many incompatible, un-written assumptions you
| discover that hadn't been ironed out.
| AmenBreak wrote:
| [dead]
| sam_lowry_ wrote:
| "Premature optimization is the root of all evil".
| esbeeb wrote:
| So very funny! In a highly cynical way.
| kmoser wrote:
| The author is right, but doesn't seem to mention that this could
| be solved, at least in theory, with better project management.
| Devs focusing on the wrong thing? Project manager should be on
| it. Scope creep? Project manager should be on it. Client asking
| for irrelevant features? Project manager should be on it.
|
| Replace those devs with ones who are focused on the right things?
| Great, but you still have the other problems to deal with (scope
| creep, uninformed clients), not to mention a host of other things
| that can derail a project, such as poor communication.
|
| tl;dr Most projects are poorly managed. Poorly managed projects
| tend to fail.
| steveBK123 wrote:
| I think the move from project management to "product
| management" really exacerbated this. The type of people that
| gravitate towards "product" vs "project" management is one
| thing.
|
| Further, project managers tend to focus on delivering the
| product stakeholders have asked for on time and on budget.
|
| Product managers however I find are frequently searching for a
| new expanded scope of stakeholders to brag they're
| solutioneering to. I find them more often in the "solutions
| looking for problems" business than I find developers, or at
| least developers are only doing it on a micro-scale, while
| product managers will take an entire team/org on 6 month
| fruitless missions to build software destined for the dustbin.
| mordae wrote:
| The moment project manager stops taking care of minutes,
| meeting agenda, getting all the stakeholders in the same
| meeting and ensuring all issues have an assignee and instead
| starts taking interest in the specifics of the project, I bail.
| eternityforest wrote:
| The main imaginary problems I commonly see are wheel
| reinventions.
|
| For the most part, the software I see works well for what it
| does, and either has far too few features, or else all the extra
| stuff they added is stuff that people actually use.
|
| On social media things are different, that's been bad and
| unsalvageable from the moment endless scrolling made it into
| something people spend significant time on.
| vinyl7 wrote:
| I'd prefer see wheel reinvention because it leads to better
| software.
|
| 1) it's debuggable 2) it's fixable 3) it does exactly what you
| need to do how you want to do it without any extra cruft and
| nonsense.
|
| Libraries or game engines are too generic to be fast and easy
| to use because they need to solve for every possible use case.
| And even then, there are still edge cases where what you want
| to do cannot be done because of the architecture of the thing
| and so you're stuck with a slow weird ducktape solution to get
| around the 3rd party code's limitations.
| davidmnoll wrote:
| I agree with this to some extent. but there's a flip side too.
|
| This mentality is often taken way too far. I had an old boss who
| wouldn't allow me to write unit tests citing this thought
| process.
|
| Even at places with decent engineering practices, I've seen so
| many examples of software where you're limited to a one to many
| relationship for something that could and easily should have been
| implemented as many to many, rendering the product useless to
| many because a product person couldn't stand to think a couple
| months ahead.
|
| Some people seem to take this idea too far and basically assume
| that if a problem is interesting or takes away a tedious task, it
| must be overengineering, premature optimization, or an imaginary
| problem.
|
| Perhaps a better way to phrase the issue would be "artificial
| constraints", which would encompass the flip side too.
| mildavw wrote:
| Yes. While it's less common, I've seen orgs struggle because
| they didn't have _enough_ imagination.
|
| Every feature is done quick'n'dirty and eventually you have
| people whose full time job is to respond to customer complaints
| and fix data straight in the production database.
| pydry wrote:
| Ive seen a lot of engineers _complain_ about YAGNI being taken
| too far but none who have seen their concerns validated by
| reality.
| quickthrower2 wrote:
| All depends on what the I is in the YAGNI. I have seen
| development be parallised where the same work is being done
| again and again by different developers in different ways
| because YAGN { maybe 2-3 days of upfront architecture and
| design for a 6 month project }. This results in bugs and
| maintenance nightmares. This was before unit tests were
| common though, so maybe unit tests may have saved it. But
| surely it was slower to develop that way.
|
| But tautologically you can't take YAGNI too far, if the
| "YAGN" part is actually true :-). But that is always under
| debate.
| dagmx wrote:
| I've had tons of times where YAGNI has bitten teams at a
| FAANG. It's been responsible for re-orgs as products have to
| pivot to meet the goals that were dismissed but turned out to
| be needed.
|
| I was creating a very important demo once, features i had
| said were important were classified as YAGNI. Leadership
| eventually saw that we couldn't deliver without said
| features. YAGNI bit those teams in the butt.
|
| these things happen all the time internally to companies but
| get ironed out internally as well.
| davidmnoll wrote:
| I have seen it validated by reality several times... more
| times than the opposite. I had a boss refuse to let me do a
| refactor that changed these sketchy dynamic field tables into
| json columns because "it's not customer facing." They were
| unable to show off features in an important demo because the
| endpoints were timing out despite putting 2 other people on
| it for 2 weeks to find code-based optimizations.
|
| 3 days later I deployed my "nice to have" fix and the
| performance issues disappeared.
|
| I've also seen a company stall out scaling for years and lose
| multiple million-dollar customers despite having a novel in-
| demand, market leading product because they refused to do
| anything to clean up their infrastructure.
| pydry wrote:
| >I had a boss refuse to let me do a refactor that changed
| these sketchy dynamic field tables into json columns
| because "it's not customer facing
|
| YAGNI isnt about not refactoring _existing_ technical debt.
| It 's about not trying to pre-empt _future_ requirements.
|
| If youre refactoring in anticipation of as yet
| unmaterialized requirements then YAGNI applies - e.g.
| generalizing code when when today there is 1 specific use
| case because tomorrow you think there will be 3+.
|
| If youre cleaning up existing code while working on it and
| the boss stops you because "it's not customer facing" then
| he's just asking you to violate the boy scout rule.
| [deleted]
| davidmnoll wrote:
| All of these definitions are fuzzy... refactor versus
| upgrade versus feature. When the people wrote it the way
| they did, they were almost certainly thinking that they
| don't need to overthink or over-engineer, and that they
| should discount hypothetical future concerns.
|
| I can give you an abundance of examples. We were creating
| a page that was going to use state in a certain way. I
| was trying to insist that we address the way state will
| be handled across pages ahead of time. These concerns
| were dismissed as premature optimization. A few months
| later we had 5 pages with the state being handled in 5
| different ways, and being synced in different ways
| between each page, complete with if statements, sometimes
| passing state through URLs, sometimes through local
| storage, sometimes through session, sometimes through JWT
| data, generally through a combo of several of them. Then
| we'd end up with confusing redirect loops for certain
| edge cases, state getting overwritten, etc.. We spend
| weeks fixing these bugs, and, eventually, weeks
| refactoring to manage state in a simpler way. These bugs
| often got caught by customers, drawing us away from
| feature delivery that was critical for demos to large
| customers.
|
| All of that could have been avoided by spending 1 day
| thinking a little harder and planning for the future.
|
| It ultimately boils down to a couple assumption that
| people like to make. (1) engineers know nothing about the
| domain, they can never predict what will be needed. That
| might be true in a large company with obscure domain-
| specific things for engineers who work far away from the
| day-to-day, but sometimes the engineers know exactly
| what's going to come up. (2) You can hill-climb your way
| into optimal program implementation. You can get to local
| maxima this way, but there are regular ways that programs
| grow based on how the business is growing and you can
| predict certain places where you will soon hit
| diminishing returns for current implementations. As long
| as you're up front about it and double-check your
| assumptions about the way the business is growing (and
| hence the application), I think there are ample places
| where you actually are going to need it.
| pydry wrote:
| >I can give you an abundance of examples. We were
| creating a page that was going to use state in a certain
| way. I was trying to insist that we address the way state
| will be handled across pages ahead of time. These
| concerns were dismissed as premature optimization. A few
| months later we had 5 pages with the state being handled
| in 5 different ways.
|
| The right time to address this was probably a bit at a
| time after the 1st, 2nd and 3rd pages. Certainly not
| before the 1st and definitely not after the 5th.
|
| >All of that could have been avoided by spending 1 day
| thinking a little harder and planning for the future.
|
| The reason why you try as hard as possible to avoid
| planning for the future is because it's really hard to
| predict the future. Moreover humans have an inbuilt bias
| towards thinking we are better than we are at it (hence
| the gambling industry).
|
| Refactoring as soon as possible after the fact will
| always produce better designs than up front planning for
| this reason.
|
| >there are regular ways that programs grow based on how
| the business is growing and you can predict certain
| places
|
| This is the kind of phrase that makes alarm bells go off
| in my head that somebody SHOULD be following YAGNI and
| isnt.
|
| If it's defaults in a well worn framework that doesnt
| railroad you then fine but anything more than that - red
| flags all around.
| IshKebab wrote:
| Yeah I agree. I think the biggest mistake people make when
| applying YAGNI is not considering how difficult it will be to
| change later. If it's just some hard-coded value that you could
| easily add to a config later? Fine. YAGNI.
|
| If it's something more fundamental like language choice or
| system architecture... Well fine YAGNI _now_ but if you ever
| _do_ need it you 're screwed.
| dtagames wrote:
| The author hits the nail on the head with his claim that
| imaginary problems are _more fun_ than real ones.
|
| As developers and smart folks in general, we like complicated
| problems that are big and far away. How many times have I heard
| in a meeting, "Yeah, but when we have 1M users..."
|
| It's great fun to think your product will get to 1M users. It's
| also very unlikely. It's not nearly as fun to finish and ship and
| market and monetize the half-broken thing the team is working on
| now. Yet that's the only way out and the only way anyone gets to
| 1M users to begin with.
| Dudester230602 wrote:
| Reddit has 1M users and is half-broken, yet monetization is
| still a problem.
| eddythompson80 wrote:
| Reddit has 1M users? Where are you getting that from? The
| only sources I could find suggest 50M daily users, 400M
| monthly users.
|
| https://thehill.com/business/despite-widespread-protest-
| redd...
|
| https://en.wikipedia.org/wiki/Reddit
|
| https://backlinko.com/reddit-users
|
| https://www.oberlo.com/blog/reddit-statistics
|
| https://www.businessofapps.com/data/reddit-statistics/
| Dudester230602 wrote:
| 1M+ was implied. I am sorry I forced you to go on a stats-
| collection side quest.
| eddythompson80 wrote:
| So what's your point exactly? The type of problems you
| have to solve for 1M users is completely different than
| 500M users including profitability.
| [deleted]
| astrobe_ wrote:
| Not the first time the issue has been pointed out:
|
| > Simplify the problem you've got or rather don't complexify
| it. I've done it myself, it's fun to do. You have a boring
| problem and hiding behind it is a much more interesting
| problem. So you code the more interesting problem and the one
| you've got is a subset of it and it falls out trivial. But of
| course you wrote ten times as much code as you needed to solve
| the problem that you actually had.
|
| [1] http://www.ultratechnology.com/1xforth.htm
| _fat_santa wrote:
| As a solo dev on a project, I constantly re-evaluate whether
| the thing I am working on is beneficial to my users or if it's
| an "imaginary problem" as this post describes. In a large
| software project you always have a laundry list of things to do
| from: "fix the date format on this email template" to
| "implement a better feature flag system". While I'm tempted to
| always work on the "fun stuff" (the feature flag system), I
| make myself work on the "boring stuff" (fixing the date format
| on an email template) because I know that's what users need.
| Occasionally you get an intersection where the cool fun an
| interesting problem is also the most pressing one but I found
| those times are few and far between and most times I have to
| decide between the "cool fun [imaginary] problem" and "the
| boring [real] problem".
| icedchai wrote:
| Reminds me of a PM I used to work with. "Will this work for
| 1000 simultaneous users?" After almost 2 months, we have less
| than 100 users total, maybe 5 of them log in a day, and maybe 1
| will actually do anything of interest.
|
| There is no _technical_ problem. The problem is nobody worked
| on actually marketing the product. Build it and nobody shows up
| is the norm.
| mnd999 wrote:
| I've worked somewhere like that. Our baseline requirements
| for concurrent users were based on the numbers required for
| the product launch team to maximise their bonus.
|
| We never saw anywhere near those numbers in production, but I
| don't really blame them - it was a big company and you do
| what you can to get ahead. A lot of money was spent on
| infrastructure that wasn't needed but nobody seemed to care.
| TuringNYC wrote:
| I was interviewing with a company that had barely any
| customers and they were asking scaling questions with Spark,
| etc. The salaries they paid could barely hire a team capable
| of dealing with the complexities of Spark, so they asked,
| "what would you do."
|
| I told them I'd buy another stick of RAM and scale vertically
| until I had more customers, and save money on staff in the
| meantime. The interviewer went cold, I didnt get the job.
| baq wrote:
| Sounds like a dodged bullet.
| codegeek wrote:
| ""Will this work for 1000 simultaneous users?""
|
| Whenever someone asks me this question, I reply with a
| question "How many simultaneous users do you/we have today
| and what is our projection say for 12-18 months from now ?".
| If the answer is not clear, I tell them not to worry yet. If
| the answer is very clear but numbers are much smaller today
| (say 5-10), then I challenge them on where they think they/we
| could be in 12-18 months. A lot of times, it helps the other
| side see that they are mostly asking "How long is a piece of
| string".
| mkl95 wrote:
| I recently added a couple of constants to some project. One of
| my teammates said it wasn't a good idea, because we could have
| hundreds of similar constants eventually.
|
| Those constants represent the markets supported by that app. By
| the time the app supports even a few dozen markets, every
| engineer involved will have exercised their stock options and
| left.
| muskmusk wrote:
| > The author hits the nail on the head with his claim that
| imaginary problems are more fun than real ones.
|
| Not necessarily. It's just that most developers have never
| worked in a setting where they got to work on problems
| properly.
|
| Solving real problems for real people is very addictive. There
| is a reason some people like working for startups. It's because
| you live very close to your users and when you make them happy
| you know.
|
| The second interesting fact is that if you just plow ahead and
| solve many real problems fast you will eventually run into
| problems that are both real and interesting.
|
| After having tried that there has been no going back for me. I
| am allergic to imaginary problems. It feels as pointless as
| watching people who are famous for being famous argue on TV.
|
| I think we are all victims of our feedback loops. (University)
| Education sublely teaches us that the only important problems
| are those that are very difficult and preferably have never
| been solved before. Those same problems also make for better
| blogposts. In the real world the incentives are mostly
| opposite. Problems with no known solutions (or only really
| difficult solutions) are generally bad. They can be worth it,
| but you should stay away from them until you know that are
| worth it. Software engineers seem to almost pride themselves on
| not knowing what their users want.
|
| It takes a while to scrub all that bad learning out and replace
| it with something better. Unfortunately some people are stuck.
| paleotrope wrote:
| I am dealing with that today. Talking about scaling out to
| hundreds if not thousands of aws accounts and I'm like, "we've
| added 6? in two years?" Why are we wasting time on this?
| TillE wrote:
| I remember having a similar argument with someone saying that
| your C code has to compile and work on every platform that
| exists, including weird CPUs with known bugs.
|
| Unless you're working on something like the Linux kernel,
| that's an imaginary problem.
| lmm wrote:
| "Newer versions of the compiler build your code with security
| vulnerabilities" is a very real problem in C. E.g. since
| x86_64 has no aligned memory access instructions, a lot of
| programmers assume there's nothing wrong with doing unaligned
| memory accesses, but actually recent gcc/clang will happily
| compile those into RCE vulnerabilities.
| qaq wrote:
| Now you have a whole bunch of New SQL databases that will scale
| past whatever number of users you can imagine. So your good old
| Django or Rails app can scale to 1M or 10M users without you
| doing anything exotic. That's not "fun" though.
| tracerbulletx wrote:
| This is why I think running a small business was the best thing
| I ever did for my software career.
| neon_electro wrote:
| How do you manage sales?
| tetha wrote:
| And people underestimate how well some solid, dumb solutions
| can scale. Boring spring boot with a decent data model and a
| bit effort to stay stateless scales to the moon. Or, we're
| having a grand "data export" system customers use to collect
| data from us for their own DWHs. It has survived 2 attempts at
| replacement so far. At it's core, it's psql + rsync, or was
| recently migrated to psql + s3 when we decomissioned our FTP
| servers. And it's easy to extend and customers are happy
| because it integrates well.
| ilyt wrote:
| > And people underestimate how well some solid, dumb
| solutions can scale.
|
| I'd say they underestimate how long "just throwing money"
| (servers) at the problem can work.
|
| If you earn decent money now, scaling number of app servers
| 10x times to serve 10x times the traffic will still earn
| decent money. Doesn't matter that "PHP is slow", deal with it
| when your infrastructure cost warrant hiring more/better
| developers to fix it.
|
| Especially now. Pair of fat servers on some NVMes and 1TB of
| RAM gonna cost you less than few dev-months and that can
| serve plenty of users in most use cases even before any extra
| caching will be needed.
| waboremo wrote:
| Even then, you don't have to throw money at the problem
| right away. If you feel you can save time and money by
| using Rust instead of PHP (just using the two languages as
| examples, not a specific indication of Rust or PHP's
| resource drain), go ahead. Making that decision early on
| costs nothing.
|
| It's only after a project is off the ground that caring
| about these decisions winds up wasting everyone's time,
| that's when you wind up slowing momentum tremendously due
| to dangling a potential new toy in front of your team.
| tyingq wrote:
| Yep. Facebook got pretty far down the road with PHP, MySQL,
| memcached, etc.
| fauigerzigerk wrote:
| All they had to do was write a PHP compiler and a new
| storage engine for MySQL.
| ericbarrett wrote:
| The trick was there was enough growth that the savings
| from the compiler were _massive_. (I worked there at the
| time.) The inefficiency of the PHP interpreter was a
| great problem to have, because it came from the success
| it enabled.
| fauigerzigerk wrote:
| So I think the interesting question is whether the rest
| of us can learn anything from what happened there.
|
| I believe Mark Zuckerberg simply used the technology he
| knew and took it from there. That's fine. I probably
| would have done the same thing.
|
| But many people are making an ideology out of this,
| arguing that not giving a shit about performance is
| always the right choice initially because that's how you
| grow fast enough to be able to retool later.
|
| I think this is based assumptions that are no longer
| true.
|
| In the early 2000s, mainstream programming languages and
| runtimes were either fast and low productivity or slow
| and high productivity (Exceptions such as Pascal/Delphi
| did exist but they were not mainstream). And the cost of
| scaling up was prohibitive compared to scaling out.
|
| Today, you can choose any fast high productivity
| language/runtime and go very far mostly scaling up.
| rafark wrote:
| Learn what? That you should use the language that you're
| more comfortable with and then scale? Or that languages
| have become more efficient? Php 8, for example, is many
| times faster than the php 4 and 5 that Facebook was
| using.
| fauigerzigerk wrote:
| I think using what you already know remains a choice that
| is very hard to criticise. But we didn't have to learn
| that, did we?
|
| Beyond that I think there is more to unlearn than to
| learn from the history of the Y2K batch of startups. The
| economics of essentially everything related to writing,
| running and distributing software have changed
| completely.
| ericbarrett wrote:
| I take away two lessons from it, which are in a kind of
| essential tension that can only be mediated by wisdom and
| experience:
|
| 1) Pick technologies that you can optimize.
|
| 2) Don't over-optimize.
|
| Also, the concept of "optimization" here has very little
| to do with the language itself. It's far more about the
| overall stack, and it definitely includes people and
| processes (like hiring). It's not like FB invested $0
| toward performance before swapping out PHP interpreters!
| Its massive caching layer, for example, was already
| taking shape well before HPHP (the C++ transpiler which
| preceded HipHop), not to mention the effort and tooling
| behind the MySQL sharding and multi-region that still
| exists in some form today. Many backend FB services were
| already written in C++ by 2010. But they had already gone
| very, very far--farther than most businesses ever will--
| on "just" PHP. Heroics like HPHP only happened after
| enormous pipelines of money were already flowing into the
| company.
| ilyt wrote:
| Did they succeed because of PHP or was it just a tech
| used at the time and anything else similar at the time
| would be fine either way?
| rafark wrote:
| They succeeded because of php. It was easy to use for
| them. So it enabled them to materialize their ideas. It
| was the right tool for them. Anything else would have
| been fine either way, if it was the language they were
| the most comfortable with. In their case, it happened to
| be php.
| mikebenfield wrote:
| Well, OK. But by that logic, if the language they had
| been most familiar with was Fortran, should they have
| used Fortran for Facebook? I tend to think that there are
| actually material differences between languages and
| technologies, and it's worth knowing more than one
| language and not using terrible ones.
| rafark wrote:
| " But by that logic, if the language they had been most
| familiar with was Fortran, should they have used Fortran
| for Facebook"
|
| Absolutely. Otherwise they wouldn't have been able to
| release the actual product and keep adding features to it
| the way they did with Facebook. They'd spend half the
| time learning the "right" language & environment. That
| would have slowed them down to the point they wouldn't
| have been able to work on the actual product as much as
| they did.
|
| And feature-wise, Facebook evolved really quickly.
| ilyt wrote:
| That just sounds like "they succeeded because they knew
| _a_ programming language ", not that it was right one
| compared to competition
| cagenut wrote:
| your comment implies your understanding of the timeline
| is backwards. they had to do those things _after_ they
| had gotten hundreds of millions of users.
| fauigerzigerk wrote:
| Depends on what you consider "far down the road" and what
| they had to do before writing a compiler and a storage
| engine.
|
| How long did it take until Facebook engineers realised
| that their technology stack was not the best tool for the
| job? It definitely wasn't the day when they decided to
| build a compiler and a storage engine.
| tyingq wrote:
| I'm not sure there was really a best tool for the job in
| 2003-2004 that would have been high-level enough to be
| productive, and scalable enough to stay mostly as-is.
| Java, maybe.
| fauigerzigerk wrote:
| I agree, and I'm not criticising the choices that Mark
| Zuckerberg made at the time. But we are no longer facing
| the same situation he did. We do now have high
| productivity, high performance language runtimes. And
| scaling up has become much cheaper (relative to the
| number of users you can serve).
|
| That's why I think it can't hurt to remind people of the
| great lengths to which Facebook had to go in order to
| deal with the limitations of their chosen platform.
| tyingq wrote:
| HipHop (later HHVM) was around 2010, so they scaled from
| 2004-2010 before that became needed. MyRocks was 2015.
| Wikipedia says FB was around 300 million users in 2009,
| then 400 million users in 2010.
| fauigerzigerk wrote:
| Yes, good point. But you have to wonder what kind of
| engineering effort went into scaling PHP and MySQL up to
| the point where they decided to build a compiler and a
| storage engine.
| rafark wrote:
| When you have half a billion users that both read and
| write all day, you have to optimize, no matter the tech.
| fauigerzigerk wrote:
| That is undeniably true, but I do think the starting
| point still matters.
| phkahler wrote:
| >> And people underestimate how well some solid, dumb
| solutions can scale.
|
| I think this started with the old Apache web server. When the
| www got started, that server did the job so everyone used it.
| The problem was it didn't scale, so all kinds of cool
| solutions (load balancers and such) were developed and
| everyone building something bigger than a personal blog used
| that stuff. For most the root problem was that Apache had
| terrible performance. Nginx has solved that now, and we also
| have faster hardware and networks, so anything less than HN
| can probably be hosted on an rpi on your home network. OK,
| I'm exaggerating, but only a little. Bottom line is that
| scaling is still treated like a big fundamental problem for
| everyone, but it doesn't need to be.
| chefandy wrote:
| I worked with a project manager that went too far in the
| opposite direction, though. Their pushback against premature
| optimization manifested in wanting to start with a
| functionalish "proof of concept" without any real design phase
| so they can say we cranked out an MVP in the first sprint...
| and before you know it, like most non-blocking technical debt,
| the "migrate functionality to final codebase" kanban card moves
| to the "long term goals" column (aka trash) and you're stuck
| with a shitty, fragile producion codebase. The opposite side--
| trying to get everything into a final state right off the bat--
| it is like trying to play an entire 8 measure song in one
| measure.
|
| At the beginning of a project, before I write a line of code, I
| try to: a) if it's user-facing software, get some UI designer
| input to shape functionality/interactions, not styling. To end
| users, the UI _is_ the software, not just the shell, so
| mediocre UI = mediocre software. It can also illuminate needs
| you didn 't consider that affect architecture, etc.; then b)
| block out the broad stroke architecture, usually on paper, c)
| intentionally choose languages/environments/tooling/etc rather
| than reflexively going with whatever we've been using recently,
| and d) spend some design time on a reasonably sane and
| extensible, but not overly detailed data model.
|
| There's no perfect solution, but at least in my cases, it seems
| like a good middle ground.
| jtriangle wrote:
| The trouble is, an 'MVP' is often far from 'minimum' in those
| sorts of situations.
|
| The reality is that MVP should be missing most planned
| functionality and should really just be a few core features
| and functions that the rest of the application builds off of,
| the trunk of the dependency tree so to speak. That idea is,
| unfortunately lost on the majority of PM's, and ultimately it
| costs more time/money to get to a finished v1 because of it.
| chefandy wrote:
| It was actually the appropriate scope for an mvp, it was
| just an unreasonable time frame to make a solid codebase
| for anything other than a demo for the complexity of the
| project. That's fine for a genuine proof of concept/rapid
| prototype you're going to be disciplined enough to trash,
| but letting that slip into the role of your core codebase
| is like pouring a sloppy scaled-down concrete foundation as
| a test for a house, and then trying to just expand it into
| what you need.
| ozim wrote:
| We have beef with AI hallucinating - get 5 people to work on a
| problem and measure how much stuff they will make up from thin
| air.
| spencerchubb wrote:
| > secure online banking is actually quite an easy problem to
| solve . . . The storage and transfer of numbers is not a
| particularly hard problem.
|
| I don't know anything about banking software, but I have a hunch
| the author underestimates the complexity (as is typical for HN).
| The Efficient Markets Hypothesis would suggest that if it were so
| simple to make banking software, then someone would do it.
| jodrellblank wrote:
| The shareprice of META fell by 75% from August 2021 to August
| 2022, wiping about three quarters of a trillion dollars off its
| market cap.
|
| From October 2022 to now the shareprice tripled, adding half a
| trillion dollars to its market cap.
|
| Explain that in terms of the Efficent Markets Hypothesis?
| "share prices reflect all information" - what half trillion
| worth of information change came out in 2022? and what in 2023?
|
| What about insider trading laws? How can we say "share prices
| reflect all information" when we know there are people who have
| more information which would give them an unfair advantage,
| which means the current shareprice _cannot_ be reflecting the
| information they have?
| elcritch wrote:
| Easy, banking and especially banking software is not an
| efficient market.
| hinkley wrote:
| My venom for design patterns has risen over the years, and I
| think the reason is that Patterns always represent concrete
| architecture changes long before the last responsible moment.
|
| In my code I tend to leave negative space. A spot where a feature
| could logically fit, without having to really design that feature
| before we need it. And as my comfort with compound refactoring
| has improved, some code smells have fallen off of my veto list.
| If we need to do X then this solution will stand in our way, but
| we can alter it here and here if that becomes a problem. It works
| well for a team of one, but it can be difficult to express in a
| code review, when someone is adding the fourth bad thing to the
| same block of code and now I'm pushing back for odd sounding
| reasons because my spidey sense is tingling about bridges too
| far.
| api wrote:
| The hard part here is telling the difference between a pure
| phantasm of an imaginary problem and innovation. Things that have
| never been done (or never really been done well) might look as
| far off as hypotheticals.
|
| I do think that "imaginary problem" is the answer most of the
| time though. Most things that look like unnecessary complexity or
| hobby horses really are.
| seviu wrote:
| And here am I struggling not to solve memory leaks or improve
| up the build time of or speed of our app because I am stuck
| implementing the most boring of the features already digested
| by a team of businesses analyst and a design team.
|
| Sometimes boring is just pure torture.
| jameshart wrote:
| This had good points up until the point where it conflated
| banking software with 'moving a few numbers around'.
|
| There are _vast_ differences between the pathologies that affect
| small scale contract web app development as detailed at the start
| of the article, and those that affect global enterprise
| development such as is required to build large scale online
| banking systems. The biggest difference being that many of the
| things which are 'imaginary problems' for the small time web app
| are very much 'real problems' for a publicly traded company with
| responsibilities to several government regulatory agencies.
|
| And sure, these institutions are _just_ as prone to conjuring
| imaginary requirements, but it requires considerably more
| sophistication to tell the difference between 'something someone
| in the German compliance office dreamed up to make themselves
| seem important' and 'something that if we get it wrong will
| result in billion euro fines' when you're building a banking
| system rather than a podcast website.
| g9yuayon wrote:
| This is such a great article. Amazon tackles this problem by
| emphasizing "working backwards", but it ultimately depends on the
| people who enforces such cultural value. I remember in one of the
| Uber all-hands meetings, an engineer asked the CTO whether Uber
| engineers should always make sure their systems can handle at
| least a million requests per second. To Thuan's credit, he
| unequivocally said no.
| honkycat wrote:
| ---
|
| They've put their heart and soul into creating this app, and it
| has some amazing features: A state of the art
| recommendation system An algorithm generating the
| transcript of all your streams, in real time Your
| front page loads in sub 200ms times all over the world
| A streaming protocol and client build almost from scratch, in
| case you don't want to rely on Facebook live A
| service that allows you to easily integrate over 20 ad exchanges
|
| ---
|
| What a dumb article.
|
| This is just made up. If you hired consultants and they pulled
| this lawyers would be involved.
|
| I stopped reading here. Why continue reading something based on a
| fake premise.
| varelse wrote:
| [dead]
| sychou wrote:
| Well said. It's a relative of the premature optimization problem.
| I often think of them as unearned problems.
| myself248 wrote:
| Alternately, it's more fun to write sci-fi than to deal with
| today's reality.
|
| And the gap is widening...
| nico wrote:
| Imaginary problems are the root of all problems
|
| Maybe a Buddhist could say
| Aperocky wrote:
| Premature optimization is the root of all evil.
|
| Simple > Complex.
|
| It's amazing how many otherwise brilliant people dive headlong
| into project without considering these basic principals or even
| intentionally brush them aside.
| Dudester230602 wrote:
| And now we will have AAA games with poor performance and DLSS
| slapped on.
|
| Maybe optimal performance is a feature? Feature worth working
| on from start?
| Aperocky wrote:
| And here's the deal, with more years in this industry, I've
| always found that the optimal performance almost always comes
| from a simple architecture.
|
| And that performance optimization done prematurely often
| achieve complete opposite result. Meanwhile performance
| optimization done at necessity rarely have the same problem.
| klysm wrote:
| I believe Saying simple > complex doesn't actually mean
| anything because it's effectively impossible to pin down
| definitions. They are totally in the eye of the beholder.
| Solutions that are simple in one axis almost always trade of
| complexity in other axes.
| McGlockenshire wrote:
| That's why I prefer the form "Do the simplest thing that
| could possibly work."
|
| There's always going to be a minimum level of complexity.
| Sometimes that minimal level calls for throwing a PHP script
| up on some shared hosting provider somewhere. Sometimes that
| minimal level calls for an Enterprise-level design with ten
| layers of abstraction because you need to be able to
| individually unit test every aspect.
|
| Being aware of where and when to introduce complexity is half
| the battle.
| klysm wrote:
| I still don't think that's a very useful mental tool
| because it also hinges on what _you_ think is simple.
| magicalhippo wrote:
| As a good illustration, consider FEniCS[1], where you can
| write a few lines of Python code which looks almost exactly
| like the math you're trying to solve, and have it compute the
| answer. Very simple!
|
| Except to make that work there's a lot of infrastructure,
| including runtime-generated-and-compiled C++ code that gets
| dynamically loaded by said Python code to perform the actual
| calculations. Quite complex!
|
| The true skill comes in finding the right balance between
| simplicity and complexity for a given situation.
|
| In the case of FEniCS, the complexity is worth it because it
| allows the system to be used by less skilled programmers (who
| might know more about the math and physics), and the
| complexity handled by experienced programmers.
|
| For our codebase we've got junior programmers who might need
| to read and understand my code if I'm on vacation and shit
| hits the fan, so I err on the side of making it easy to read
| and reason about. Which might not be the "simplest" for some
| measures of simplicity (like fewer lines of code).
|
| [1]: https://fenicsproject.org/
| physicsguy wrote:
| I'd argue that FEniCs was a prime example of this in some
| ways, at least earlier in it's history.
|
| I started using it in about 2014. It was not exactly what I
| would call a simple project. It used to be an ordeal to
| build, could only easily be used via Docker, ported to
| Python 3 a long long time after most of it's dependencies
| did, had an unstable C++ API that changes were not
| documented for but nonetheless you were required to use if
| you wanted for reasonable performance for some
| calculations, etc. The national supercomputing centre in my
| country managed to only get one version to build because it
| was so poorly specified at the time and basically only
| supported Ubuntu!
|
| FEniCsX is considerably better usability wise, but that's
| the result of hard lessons learnt.
| Nevermark wrote:
| OMG, never has truth been so funny and yet so tragic.
|
| This article, its art and its font choice, shall be preserved
| forever in the archive of Historical Documents.
|
| Our eternal response to unnecessary complexity? "Never give up!
| Never surrender!"
|
| --
|
| ADDENDUM:
|
| The article makes a good case for formally adding "manufactured
| complexity" and "miscommunication complexity" to "accidental
| complexity" and "necessary complexity".
|
| They are quite common distinct causes.
| lewisjoe wrote:
| If anything it's the incentive system in software industry, which
| is at fault.
|
| 1. No designer is given promotion for sticking to conventional
| designs. It's their creative & clever designs that get them
| attention and career incentives.
|
| 2. No engineer is paid extra for keeping the codebase without
| growing too much. It's re-writes and the effort he puts in to
| churn out more solutions (than there are problems) that offers
| him a chance to climb the ladder.
|
| 3. No product manager can put "Made the product more stable and
| usable" in their resume. It's all the new extra features that
| they thought out, which will earn them reputation.
|
| 4. No manager is rewarded for how lean a team they manage and how
| they get things done with a tiny & flat team. Managers pride
| themselves with how many people work under them and how tall in
| the hierarchy they are.
|
| Our industry thrives on producing more solutions than needed.
| Efforts are rewarded based on conventional measurements, without
| thinking through- in what directions were the efforts pointed at.
|
| Unless the incentives of everyone involved are aligned with
| what's actually needed, we'll continue solving imaginary
| problems, I guess.
| x86x87 wrote:
| I call this "the tragedy of software development"
| wildekek wrote:
| All of those are absolutely real. There is a lack of economics
| and a surplus of optics in the game for all players.
| tzhenghao wrote:
| "Show me the incentive, I'll show you the outcome." - Charlie
| Munger
| voz_ wrote:
| Uber was a massive example of this. The best engineers kept
| their head down and just tried to keep things afloat, fixing
| bugs, etc.
|
| However, a large and insidious cadre of B tier engineers was
| constantly writing docs proposing meaningless arbitrary system
| changes and new designs for the sake the changes themselves.
| These new projects were the only way to get promoted. The
| entire e4->5->6->7 track was written in such a way that it only
| ever encouraged "TL"/"architect"types to grow.
|
| This led to constant churn, horrible codebases, and utter
| bullshit self made problems which could only be solved by
| digging a deeper hole.
|
| There are companies who handle this well. Ultimately it comes
| down to engineering culture.
| nine_zeros wrote:
| The career ladder is among the biggest fuck ups of the tech
| industry. They incentivize bullshittery more than actual
| innovation. There are more rewards for BS RFCs than in
| keeping the ship running.
| throw10920 wrote:
| They're not mutually exclusive.
|
| FOSS software has vastly different incentives than commercial
| software, yet suffers from many of the same problems:
| bugginess, poor performance, lack of documentation, feature
| misprioritization, bad UI.
|
| That alone indicates that the problem is not merely "misaligned
| incentives".
|
| Actually, you can reduce _most_ problems down to "misaligned
| incentives" if you're overly reductive enough. That doesn't
| mean that it's a useful way to think about the world.
| xyzelement wrote:
| Maybe I am biased by my background in finance tech but I saw a
| ton of guys get rewarded for what (at the time) seemed like
| boring maintenance of systems.
|
| In retrospect - it was recognized that they built or took good
| care of money making systems with little drama and that was
| well appreciated by the companies.
|
| In FAANGs I see now more of "what will get me promoted" versus
| "what is gonna make the company money" ethos.
| sirsinsalot wrote:
| > No engineer is paid extra for keeping the codebase without
| growing too much.
|
| I am. I'm paid more than most developers to run a team doing
| just this. We make minimal change, have an absolutely non-
| negotiable focus on stability and minimalism and reject any
| change that isn't absolutely driven by validated majority user
| need. Even then, the bar is high.
|
| I'm not saying this is a common situation, but it certainly
| isn't rare in my experience. Software is a vastly wide scope of
| software types and requirements. I'm paid to be ruthless, and
| to know what ruthless looks like in terms of delivering
| consistently without downtime/data loss/critical issues.
| chubot wrote:
| What kind of software do you work on? At what company?
|
| I have seen low level parts that are managed well, because
| employees have skin in the game
|
| But I've also seen a lot of what this post is talking about
| bombolo wrote:
| Until you have the star developer that starts promising the
| product manager he can do all the extra features in a week.
| And then of course none of them actually work decently or
| at all. But at that point it must be maintained by the
| whole team anyway.
| whstl wrote:
| I'm in the same boat as GP. I work in finance. CTO said he
| wanted to keep things simple and stable, so I do it.
|
| It is only possible because I'm a technical manager myself
| and I have a very competent (and technical) product manager
| working with me.
|
| But for every person like me, there are 10 other devs
| trying to cram every pattern from the GoF book in their
| corner of the codebase, so I have to spend my scarce time
| reviewing PRs.
| kylelahnakoski wrote:
| Minimal change, or minimal code? Refactoring code can make
| code smaller but depends on good testing. Applying minimal
| changes results in redundant and complicated code, but less
| likely to break existing functionality.
| jtriangle wrote:
| Bless you man, you're doing the lords work
| [deleted]
| Xen9 wrote:
| This kind of problem surfaces in a large amount of systems
| involving humans and roles.
| AndrewKemendo wrote:
| I'm going to reference this comment in the future when I build
| my next software product. Thanks
| bluGill wrote:
| There are exceptions to all the above, but only after the worst
| case burns from failure to do those things. If you are losing
| customers to competition that doesn't crash, then suddenly you
| can be the hero by making yours more stable. Of course only if
| you can do this before the company dies.
| hinkley wrote:
| There's a couple of woodworking hand tool companies who among
| other things make replicas of old school Stanley tools, the way
| Stanley used to make them (materials and tolerances). They also
| fuse the best elements of several eras or manufacturers to make
| slightly better versions. Surfaces from this one, handles from
| that one, adjustment mechanism from a third.
|
| I hope that I live to see a time when software applies modern
| algorithms to classic designs and produce "hand tools" in
| software.
| Aerbil313 wrote:
| The field of software is maturing as we're reaching the end
| of Moore's Law and time passes. Times of constant innovation
| is very slowly coming to an end, the curve is slowly
| flattening. You can already see it with general trends like
| type-safety, DX features universal in all languages (linting
| etc.), browsers finally becoming the universal OS (Wasm,
| WebUSB, GPU), more and more things being standardized every
| day.
| segh wrote:
| I'm not sure it's just incentives. Inexperienced early stage
| founders often end up solving imaginary problems, despite
| having a real incentive to get it right. The Y Combinator moto
| is "make something people want" because so many people don't.
| marcus0x62 wrote:
| And at least at the "enterprise" level for B2B software, there
| is intense customer demand for more features and,
| simultaneously, more stability.
|
| From my view, that and pressure from the analyst racket are the
| main drivers behind feature bloat with self promotion a distant
| third.
| bombolo wrote:
| Coworker of mine wrote a thing in java... it was too slow
| (intensive locking between threads)... so he rewrote it in C...
| it was crashing all the time (because he sucks), then he
| rewrote it in go. Got promoted for this feat.
| ilyt wrote:
| That's kinda what initally Go was made for IIRC. They noticed
| people which job is not programming but had to write some
| code (say some analytics or sth) often did it in Python, and
| if it was too slow they moved to C or Java and were
| predictably terrible at it, so that's why Go was made simple
| and with builtin concurrency primitives.
| bombolo wrote:
| But his job is programming. He is very proud of his C
| skills. If you listen to him, it crashed because C is
| intrinsically bad (it is difficult yes), but I guess it was
| also such a bad codebase that rewriting it made sense.
|
| He also holds a grudge against me for having dared to
| rewrite a sacred C library he wrote (that was a constant
| source of segfault and I rewrote in 1 afternoon).
| ilyt wrote:
| Sounds more like his job is producing tech debt. I saw
| few people like that, basically none of their code was
| left as most of that needed to be eventually replaced coz
| it was shit.
| analog31 wrote:
| You can still get away with these things if your only user is
| yourself or maybe a small handful of non-enterprise folks. This
| could be why the so called "scientific" programmer feels like
| they can be as productive as a team of 10+ software developers.
|
| And also why the most frequent request from the users is:
| Please don't change anything.
|
| The principal-agent problem looms large in software.
| sh34r wrote:
| I agree with just about everything you've said, except that bit
| about rewrites. Rewrite projects typically go down in flames,
| and on the rare occasions that they don't, the business
| stakeholders are still mad because their precious feature
| factory was down for maintenance for months.
| Hackbraten wrote:
| > months
|
| Please.
| yieldcrv wrote:
| and the re-writes have to be in a trendy language that other
| companies are using, just for the engineer to stay relevant.
|
| everything about engineering group decisions are about creating
| a reason to use a newer framework in a way other people can
| vouch for.
| rapht wrote:
| You can think of it in even broader terms: being/staying lean,
| re-using tried and tested things, adapting your requirements to
| widely available solutions rather than developing custom
| solutions to fit your requirements, making everything work more
| efficiently, etc -- all those resource-minimization issues are
| "less" problems: not good problems to be working on when your
| raison d'etre is "more" -- and that's the only raison d'etre
| for a lot of people and actually for all businesses. (Obviously
| there are also specialists for doing "less" "more":
| unsurprisingly, they are generally paid a cut of savings.)
| joshlemer wrote:
| I don't know, the more I advance in my career, the more I see
| it as the opposite. Wide eyed developers with big designs, who
| are obsessed with the technical aspects of a solution, who
| disregard the practicalities, long term implications at the
| social level (who is going to maintain this, do we have people
| that have that skillset, is this worth the effort, does it
| really matter to be this elegant, or is it more important to
| ship quickly and economically) come off as a bit immature and
| the more effective engineers who understand these priorities
| are given more respect and authority.
| gopalv wrote:
| > the more effective engineers who understand these
| priorities are given more respect and authority.
|
| The problem with "given more authority" I see is that
| management plucks these engineers out to make their day job
| basically "sit in meetings" if you're even slightly effective
| at simplifying life for everyone else.
|
| Because that is the place of most leverage to place those
| people, but then those people are in a constant tug-of-war
| with the first group of "fresh ideas".
|
| Eventually, the people who are in charge of the "prevention
| of bad architecture" become the bad guys because they (or me,
| I'm projecting) get jaded into just finding out what's wrong
| with something as fast as possible to be able to keep up with
| that workload.
|
| You go from a creative role to a fundamentally sieve role
| with destructive tendencies, where you are filtering out the
| good from the bad as fast as possible, be.
|
| First of all, not all new ideas are bad and "there's
| something bad about X" is not a "let's not do X".
|
| Secondly, going from making things to shooting down things is
| intellectual suffering if you have a bit of empathy.
|
| Some people on the "committee" with you don't have empathy &
| literally enjoy it - you're either trying to damage control
| on a case-by-case or building a "these assholes need to be
| fired" doc out of the meetings.
|
| I realized what I would become if I conflated authority and
| respect ("respect my authoritah!").
|
| Quitting was really the only way out of it. But it wasn't
| hard to explain to my spouse that i needed to leave for a job
| a level down and which paid half as much, because she could
| see me bringing my "why the hell do we have to do this"
| attitude home & to family decisions.
| tacitusarc wrote:
| As a team lead, I've found it really difficult to keep
| curious, smart, young engineers on track. Everyone wants to
| go off and build shiny things instead of solving real
| problems. I have to find enough shiny problems that actually
| need solving to balance out the daily grind. Interestingly, I
| also find it difficult to instill a sense of meticulousness,
| and how important it is to write code in a way that reduces
| bugs. Clever engineers come up with clever, complicated
| solutions that are written quickly and rely on coincidence to
| function. Life experience is the best teacher for this, but I
| often need to step in. I'm still not sure what the balance is
| there.
| stuckinhell wrote:
| The problem for a lot of the social level issues is that it
| is pure pure politics.
| llanowarelves wrote:
| I like that it's this way so we can easily compete with these
| dysfunctional companies. Don't fix them :)
| ronnier wrote:
| I really think we have too many people working at most
| companies. It pushes people to the extremes and edges just to
| have something to work on. Managers need more people under them
| to get promotions. And managers want to manage managers to keep
| moving up. They fill teams of people on products that could
| really be ran by a fraction of the engineers. But that's not
| where we are, we are on large teams working on small areas of
| the product inventing areas to build in and often ruining the
| product as a result.
|
| We also get slower with so many people. The coordination
| overhead is killer and losing context as the product is sliced
| up into small parts that move on without you
| CBLT wrote:
| > we have too many people working at most companies.
|
| I half-disagree with this. My take is significantly more top-
| down: senior management has a deficient concept of how
| product development works. They believe Manpower is to be
| spent to achieve revenue, either by directly selling the
| result as a product (e.g. airplanes selling wifi to
| passengers) or by it being a differentiating feature for the
| sales department. This causes every allocation decision (like
| hiring) to fundamentally be biased around getting a tangible
| return: by creating new projects, new features, and new buggy
| microservices.
|
| Further, since management only has two knobs (manpower and
| timeline) to play with, they like to move them to feel like
| they're optimizing the project. It's always the same
| fallacies, too: "we hired more people so we can create
| explosive growth", "we created ambitious timelines, now we're
| striving to fill them" etc.
|
| I don't have a solution for this, except to note that it can
| be mitigated by managing up. Construct your own narrative,
| and take advantage of the fact that the non-technical people
| above you govern almost entirely by gut feeling.
| morning-coffee wrote:
| ^ this ^
|
| Until we figure out a nice metric for "removing complexity" and
| then rewarding for it, it's not likely to change, IMO.
| pavlov wrote:
| _> "No designer is given promotion for sticking to conventional
| designs. It 's their creative & clever designs that get them
| attention and career incentives."_
|
| This is a massive change from my first software industry job in
| 1997.
|
| I was essentially a "design intern who knows HTML" on a team
| that built a shrinkwrap Windows application for enterprises.
| The core of the design team was a graphic designer, a cognitive
| scientist, an industrial designer, and a product manager with
| industry experience in the customer domain.
|
| The application was Windows native. User research was conducted
| on site with scientific rigor. Adhering to platform guidelines
| and conventions was a priority. I think I spent a few weeks
| redrawing hundreds of toolbar icons so they'd be in line with
| the Office 97 look (the kind of boring job you give to the
| junior). If the app stood out on the Windows desktop, that
| would have been considered problematic.
|
| Today a similar design team would only have a graphic designer
| and a PM, and neither of them would care the slightest about
| platform guidelines or customer domain. The UI is primarily an
| extension of the corporate brand. Hiring a cognitive scientist?
| Forget about it...
|
| Everything certainly wasn't perfect in the Windows/Mac desktop
| golden era. But the rise of the web wiped out a lot of good
| industry practices too.
| aldanor wrote:
| Today they might have a psychologist on the team to research
| which buttons may serve as dopamine triggers so you're a lot
| more likely to upgrade to Premium before thinking it over
| pavlov wrote:
| Right. Making people click on things they didn't mean to
| and buy things they didn't want -- those goals were not
| even a part of the 1990s UI paradigm.
| hnlmorg wrote:
| 1990s design was all about preventing people from
| accidentally doing actions they might not have wanted to.
| Even down to the "Are you sure you want to quit"
| dialogues that were all the rage.
|
| It's sad just where we are now compared to the design
| goals of old.
| WinLychee wrote:
| There's been a large influx of people chasing dollars and
| status, they could not care less about the product or who
| uses it. You can still find orgs that do care, but they're
| swiftly pushed out by the VC-funded "growth at any cost"
| model or are acquired into oblivion.
|
| The indie scene is looking excellent however, a lot of
| programmers who have already made their money seem to be
| pushing excellent hobby projects out.
| jakubmazanec wrote:
| I have another theory: it's all about the screen size. When
| you had only 320x240--1014x768, you simply MUST have thought
| about UX (in the sense of "How can I fit all this info in
| this little space?"
|
| Now you don't have to. So no one does.
| lewisjoe wrote:
| From a person who started using computers from the early
| 2000s era:
|
| THANK YOU!
|
| None of the current SaaS apps I use can come close to the
| experience of using softwares from that era.
|
| Take a simple list view of a typical Windows/Mac software?
|
| 1. Command clicking selected multiple objects
|
| 2. Shift clicking selected a range.
|
| 3. Right clicking brought up selection actions.
|
| 4. Double clicking opened an object.
|
| This pattern was followed in almost list views and there was
| no re-learning and surprises.
|
| Now can you say the same about the list views of modern web
| apps?
|
| Can you apply the same list selection experience across
| Google Drive and Microsoft OneDrive and Apple iCloud? Nope.
|
| That's were we failed as an industry. We let a lot of
| designers run too wild with their ideas, to put it bluntly.
| ilyt wrote:
| And everything had a keybind so if you worked in software
| every day you could be as fast as cli nerds.
| someweirdperson wrote:
| And not even be slowed down by animations.
| bombolo wrote:
| The problem with the controls is mostly because they don't
| want to pay for Qt (multiplatform toolkit), so instead
| every company (badly) implements their own controls in HTML
| to save money. I suspect ultimately they waste much more
| money than they save.
| whstl wrote:
| Qt isn't even in the radar of most companies currently
| building multi-platform applications in HTML. And it
| won't be soon, for two main reasons: developers able to
| use it are expensive, and most Qt applications in the
| wild still have the "uncanny valley" look and feel about
| them on every OS but Linux.
|
| Not to mention that with SaaS being more profitable than
| selling unlimited-use licenses, a lot of apps also have
| HTTP backends and webapp versions, which can share a lot
| of HTML/CSS/JS code with a browser-based desktop version.
| Think of Slack/Discord/VSCode/etc. Sure: Qt, Flutter, etc
| also have web versions, but they just don't look/feel as
| good in the browser as an HTML app normally can.
|
| If you want a "Premium" native look and feel, people
| gotta go directly to the source: native APIs. Qt won't do
| it without a lot of work. Lots of companies have separate
| Android and iOS teams. Or they go directly to HTML when
| there's not enough cash (or even things like Flutter,
| which look ok in mobile). High-quality macOS apps, like
| those made by Panic, Rogue Amoeba, etc, use Cocoa
| directly.
|
| Standardized controls and shortcuts unfortunately end up
| being collateral damage in all of this.
| lfowles wrote:
| Those four actions worked for me on the Google Drive web
| interface
| lewisjoe wrote:
| Great! Now try it in any other list view in any other
| app.
|
| Maybe the list of docs in https://docs.google.com?
| evandale wrote:
| On my phone so it's hard to check, but Gmail's ctrl and
| shift clicks work really well and is intuitive to me. I'm
| shocked they wouldn't use the same mechanics everywhere.
|
| Best example: Gmail is one of the only webapps I'll ctrl
| click a few items at the top of the list, ctrl click a
| few in the middle, and then shift click to the bottom and
| it works exactly how I'd expect - everything stays
| selected and the shift+click selects from your previous
| click to the next item. I think it gets wonky if you
| change directions but I can't imagine how I'd expect
| ctrl+click item 1, 2, 9, 10, then shift click on 4 would
| work.
| ilyt wrote:
| Remember times where you could change the theme and all of
| the apps followed suit ?
|
| Even in Linux there were tools to sync gnome with QT look so
| you could have one theme applied to every app for nice and
| consistent look, all the way to how the common icons look.
|
| Nowadays ? Every fucking app gotta have their own different
| styling. Will the setting icon be three dots, gear, or honey
| badger ? WHO FUCKING KNOWS. You'd be lucky if you even get a
| choice between light and dark theme
|
| But hey, we can write same code to work on windows, mac and
| mobile ! It will work shit in all of them and be slow but we
| don't care!
| AndrewKemendo wrote:
| Oh man I totally forgot about that. Thank you for the
| reminder.
|
| Total flashbacks to windows 95 and every so often changing
| the windows color, text font etc. for the entire system
|
| Good times
| wheybags wrote:
| I remember that theory. I also remember the reality that if
| you changed your background colour to anything but white,
| some app, somewhere, was going to become an unreadable
| black text on black background mess.
| nicoco wrote:
| > Even in Linux there were tools to sync gnome with QT look
|
| There are still such tools, you don't have to use the past
| tense here.
| thwarted wrote:
| And it got worse with client side decorations. Now even
| window interactions are app-specific and don't adhere to
| global settings.
| pdntspa wrote:
| Even better, every app is doing their own styling so they
| can all look like Discord
| chillbill wrote:
| I don't think it's as easy as you're making it to seem. The
| issue is that there are unintended consequences to each one of
| those points you mentioned. I'm pretty sure a substantial
| amount of thinking goes into software design from all aspects
| and it's a bit reductive to say that it's just lack of
| incentive. Humans doing software are not some machine learning
| algorithm to train with reinforcement learning techniques.
| [deleted]
| duxup wrote:
| > It should be noted that this issue isn't unique to developers.
| Management, sales, HR, support, legal, and even accounting
| departments have their own unique ways of creating imaginary
| problems. They try to involve themselves too much in a decision,
| when their presence at a meeting is just a formality or wasn't
| requested at all. They overemphasize a minute problem that is
| related to their role, or hire teams much larger than necessary
| to illustrate their importance.
|
| I run into this more often than problems I imagine. A whole
| series of what ifs and folks imagining things. The worst part is
| the fixes to their imaginary problem are usually not well thought
| out and drive things towards worse choices.
|
| I'm a big believer in getting version 1 out the door as problems
| people imagine often... are never relayed by the actual customer.
|
| I often work with some routing software (let's say routing
| packages). There is a simple mode that works great. Anyone can
| use it.
|
| The issue is people want to establish say 20 rules about how /
| when / what is routed. Business folks insist that it be "easy"
| for "anyone to use" just like the existing easy mode.
|
| This is doomed from the start. We can make it easier for sure,
| but if you have 20 rules with different weighted priorities:
|
| 1. It is complex for most people to think of. It will look
| complex because it is complex.
|
| 2. That's ok because the guy with 20 rules probably has thought
| about them and understand they have 20 rules.
|
| Then we give them UI to visualize it all and customer is happy.
|
| But the business folks are upset because the visualization is
| complex... and there we are again.
|
| For the record I usually get through this slog and everyone is
| happy in the end, but it is a slog due to imaginary problems.
| vbezhenar wrote:
| How do you manage boring part though? Going mad because of
| boredom is a real thing. I definitely agree that some of my job
| is caused exclusively by my need to keep myself entertained. But
| what's the solution?
|
| Another factor is resume driven development. Yes, you can frown
| upon it all the day, but in the end I'll switch company and I'll
| need to find a new job. And, like it or not, but everyone these
| days wants a lot of experience from their workers. I'd love to
| write C89 in the dark corner for the rest of my days for
| reasonable compensation, but I don't see those jobs, what I see
| is billion keywords k8s spring boot react query metrics jaeger
| aws yada-yada.
| morning-coffee wrote:
| Try to find other real problems to work on that are _different_
| from your current boring parts? The new problems might
| eventually become boring as well, but often the change and
| fresh perspective is enough to pique your interest in a
| motivational and productive way.
| notatoad wrote:
| i think it's important to acknowledge when you're working and
| when you're playing. working on fun things isn't inherently
| bad, and can lead to actual productivity when the things you
| learn during your fun geeky tangents turn out to be useful to
| the actual work.
|
| but if you start convincing yourself that the fun distraction
| is the actual work you need to be getting done, then you might
| have a problem. (not to say that actual work can't be fun too.
| jut saying make sure you know which is which)
| dan-robertson wrote:
| I don't know what is going on with this article. The first half
| is a maybe reasonable description of a common way for certain
| kinds of contracts to go wrong. But obviously lots of software
| doesn't get developed in this sort of arms-length way. I would
| say that imaginary problems (as the author defines them) cause
| failed projects by consultants/contractors.
|
| I find the rest of the article to be bizarre. The discussion
| around retail banking software seems unacceptably incurious and a
| very likely incorrect diagnosis of the cause of the problems (it
| basically stoops to an 'I could do that in a weekend' level of
| criticism[1]). It then transitions to a screed about Goldman
| Sachs which is, as far as I can tell irrelevant (Goldman do very
| little retail banking; their software development will be quite
| different to that done for retail banking), and then some
| description of how the author thinks (all?) large companies are
| (mis)run. I don't know if Goldman was meant to be a prototype for
| this model of company management but it seems like a particularly
| strange example (in particular, they still will have some
| remnants from the culture of being a partnership, so they'll be
| run somewhat differently from other big investment banks).
|
| I found the second half did not ring true. I'm sure software
| projects fail at big companies (including retail banks, Goldman
| Sachs, other investment banks, tech companies, and so on) but I
| don't find the reasons given in the article convincing to the
| extent that I think that section could have been written by
| someone who had only ever worked at very small companies. But
| maybe it's just me and most companies are so obviously terribly
| wrong in these ways that no one even bothers to write about them
| and so I only see subtle ways they go wrong like projects dying
| off due to management acting in bad-faith ways or rewarding
| people for things that aren't actually so good for the company or
| whatever.
|
| If you're interested in better discourse around certain kinds of
| bureaucracy, look into _moral mazes_.
|
| [1] generally 'I could do that in a weekend' is code for 'I could
| do some minimum thing that doesn't actually solve whatever the
| important problems are in a weekend'
| mlhpdx wrote:
| The second part might be summarized as "when technology starts
| to diverge from the business model, or vice versa, both become
| messy."
| rco8786 wrote:
| I frequently refer to this as "It would be cool if" driven
| development.
|
| Crucial to fight against this kind of stuff.
| adamnemecek wrote:
| This sentiment get repeated a bunch but I doubt it's really true.
|
| Bad languages and tooling is the root of bad software.
| suid wrote:
| A long article that can be succinctly expressed by the many
| variations of this cartoon: https://softwarehamilton.com/wp-
| content/uploads/2013/02/swin...
| victor106 wrote:
| Great advice, spot on
|
| At work we have this terrible "Enterprise Architecture" team
| comprising of highly paid people who haven't written a single
| line of code and who don't know the intricacies of our business
| but keep proposing complicated "Event Driven Architectures" and
| "Micro this and Micro that" and just reciting the latest buzz
| words just to keep appearing cool.
|
| It's insane how much total cost they add to the organization,
| both directly and indirectly.
| jbmsf wrote:
| I consult as a software architect and my job is mostly the
| opposite of this: asking people what problem they are trying to
| solve and why they haven't considered $EXISTING_SOLUTION
| basilgohar wrote:
| I always find it bizarre how people like this can operate.
| After almost 20 years of software development, I've considered
| seeking some kind of an architect role, but I cannot, for the
| life of me, imagine operating as one without working closely
| and collaboratively with the development team on a solution,
| rather than just dictating how things should be done "from on
| high". But that may just be a personality thing, I don't know.
| intelVISA wrote:
| > I always find it bizarre how people like this can operate.
|
| They are acting rationally within their belief system of
| making money.
|
| Enterprise software is exactly that, software used by
| enterprise -- it doesn't signify any good qualities (far from
| it) only that it provides a cost-effective software solution
| to a defined business need.
|
| The issue is when corps get bailed out, overfunded, or have
| revenue mostly outside of software (e.g. gov't contracts) as
| it eliminates cost-effective from the equation... so you just
| end up with buggy messes (code as a cost center).
|
| You'd have to work in the tiny niches where tech is the true
| product to find good development ...and even then...
| t43562 wrote:
| "real architects" write code and simply hop from one team to
| the other so that they have a reasonable picture of the
| overall system and can try to guide all the teams to make
| harmonious choices and possibly even reach some goal.
|
| This still results in a lot of compromises and problems.
| Anyhow they should be there talking to the developers in a
| 2-way fashion so that then end result is not entirely "from
| on high".
| noirbot wrote:
| I've seen this even without the code - them just bouncing
| between teams and sitting in on many meetings and sort of
| being the common note-taker who then knows where almost
| every team is going, what they need, and what cross-team
| work could be done to improve everyone's life.
| pydry wrote:
| I haven't ever seen one of them.
|
| IME architects tend to be people who tell your team that
| you should be using Azure Cosmos after a Microsoft salesman
| takes them out to lunch. They last coded 5 years ago.
| jbmsf wrote:
| They exist - I am one - but it doesn't work unless your
| leadership wants someone who doesn't fit in existing
| hierarchies. I tend to consult and if I go somewhere
| where I have prior relationships with leadership, it
| works. If not, I get treated as part of someone's narrow
| reporting chain and all the incentives are wrong.
| ano-ther wrote:
| Ah yes. This explains very well why, when I ask our corporate IT
| for a static website with essentially text + some PDF downloads,
| I keep ending up in a "web platform" project based on a
| fiendishly complex CMS that is made for running large-scale
| e-commerce sites -- of course delivered after ages and requiring
| multiple rounds with the CFO to justify the increased budget.
|
| Been through that at several companies now.
| [deleted]
| Wowfunhappy wrote:
| Isn't this why companies have employees with different levels of
| experience?
|
| Need a bog standard app to stream audio files? Give it to the
| person you hired right out of college, or maybe even the summer
| intern. She's never built something like this before, so to her
| it will be a challenging novel problem. A (somewhat) more
| experienced developer may need to provide initial guidance and
| review code, but that's a comparatively minor time investment,
| and besides, the act of mentoring someone else should keep it
| interesting.
| sigstoat wrote:
| > Isn't this why companies have employees with different levels
| of experience?
|
| this runs into another common mistake businesses make: putting
| people onto a task because they're available, not because
| they're suited to it (in any sense).
|
| the junior person (+ a little mentorship) would be great for
| the job, but they're mired in some big project. but hey, you've
| got this super senior fellow sitting around waiting for work,
| and we can bill the customer more for them, anyways.
| emodendroket wrote:
| It's impossible for a large organization to operate as
| efficiently as a tiny one but I also don't really believe the
| article's implied claim that "a couple smart guys" could solve
| essentially any given problem to clients' satisfaction within a
| reasonable timeframe.
| brigadier132 wrote:
| It seems like the fundamental problem for the scenario presented
| in the article was an inability of the customer to communicate
| their strategy and a completely hands off approach during
| implementation when they should have had at the very least
| biweekly checkins with developers with pre-negotiated milestones.
| roncesvalles wrote:
| The fundamental problem is that a non-technical person has
| specced out a technical product without input from technical
| people.
|
| A restauranteur wouldn't develop a menu without input from a
| chef or prior experience as one. A layperson wouldn't design a
| real building without input from an architect or engineer.
|
| Yet for some reason a myriad of non-technical people (read:
| laypeople) feel empowered to design, spec, and strategize about
| software. It still boggles my mind that "product management" is
| a real profession.
| dagmx wrote:
| Yes, I agree. This is fundamentally a communication issue not a
| "developers run amok" issue to me.
|
| They shouldn't be checking in after two months. They should
| have regular check ins.
|
| They shouldn't have had such a vague brief.
|
| They should have discussed a wide range of off the shelf
| options from the get go to see if they needed something bespoke
| or not.
| gedy wrote:
| Sort of related, but this is one reason I moved into "Frontend"
| about 10 years ago. I started seeing over and over that when our
| (SaaS) projects didn't start from what the customer sees, teams
| usually got distracted with imaginary or hypothetical design
| issues. It was a lot more effective to iterate from the visible
| features, and then let that drive much of the backend design,
| APIs, development timeline, etc.
|
| This meant I needed to deal with more JavaScript than I
| originally intended with my career, and eyerolls from backend
| architect types, but projects go much smoother than in my past,
| that's for sure.
| swader999 wrote:
| Imaginary problems aka gold plating and yagni.
| mlhpdx wrote:
| > They might realize Debra has been sitting in that corner,
| staring at uptime graphs of the internal server farm for 10
| years, despite the fact that the company moved to AWS five years
| ago.
|
| Ouch. The tone of the article is a little harsh, and I'm not sure
| if snippets like the above are intentionally hyperbolic, but
| there is a fair amount of truth in it.
|
| Most of my career has involved convincing peers to do less, and
| solve simpler problems with simpler solutions.
| dagmx wrote:
| I know it's just an arbitrary number picked but this bit jumped
| out at me:
|
| "You've just wasted $15,000 on two months work with a team of
| contractors"
|
| The project may also have been doomed because $15k is not very
| much for something like they described.
|
| But again, fully aware that they probably picked a random number.
| I'd have just added another zero to make it more realistic.
| totallywrong wrote:
| 15k is rather high for those specs. A single competent dev can
| build that in a month.
| dagmx wrote:
| 15k for a single dev over a month, sure. 15k for a team over
| multiple months is different though.
| casperb wrote:
| In our agency 10 years ago we build such websites, it would
| cost 3000-5000 dollars max. Just with PHP and a simple self
| build CMS. Including a simple responsive design. We also hosted
| around 250 of such websites on a single dedicated server. It
| was very very fast.
| golergka wrote:
| Where are your developers located and what what are their
| salaries?
| casperb wrote:
| In the Netherlands, Europe. We had a small agency with 3
| friends. We did around 250k a year in revenue.
|
| Exactly the type of team that is super productive for these
| kinds of job imo.
| Lacerda69 wrote:
| 150.000$ for a podcast app with zazzle shop and google ads
| integration?
|
| That sounds really high to me. I personally found 15k way too
| high already; guess it depends on the
| details/market/circumstances
| dagmx wrote:
| It could be both too high or too low depending on the
| communicated expectations of the client. Which is I think the
| real issue here anyway.
|
| But let's say 15k for two months of a team of contractors.
| That's 7.5k/mo. A team says at least two, but I think given
| they mention sales etc, that's 3-5 people. Netting
| 2.5k/person before you take out built in profit margins,
| healthcare (because it's dollars, I assume America) and more.
| That's roughly 1.5k/person per month. (Of course they could
| have multiple projects but even then that's a low amount imho
| for a contractor with sales)
|
| If they're expecting an off the shelf solution, then they're
| getting fleeced on the costs and 15k is too high, but if
| they're going to a company that does big solutions than they
| spent too little.
|
| There's too little info in general
| TrackerFF wrote:
| In the world of entrepreneurship, you mostly find the extremes.
|
| Either you have the bootstrap founders that will trawl through
| fiverr to find the cheapest labor (the same types that will
| scoff and get insulted at anything over $10k), or you have the
| well-funded founders that will pay whatever it takes.
|
| From experience: Cheapskates and low-ballers will never be
| happy. They always want something free, more haggle room, more
| discounts, and always have high demands and expectations. The
| best thing one can do is to price yourself away from them.
| notatoad wrote:
| i think you might be trying to solve the author's imaginary
| problems.
|
| all the author needs is a wordpress site with a couple plugins
| and a few weeks of back and forth on the design work. if you
| can't make a good profit on that with a $15k invoice, you're
| doing something very wrong.
| dagmx wrote:
| The problem is that their brief is too vague and the real
| issue is communication.
|
| At no point is it clear that they've discussed off the shelf
| solutions, or infrastructure (storage, server hiding, CDN
| etc).
|
| If they had, then they either messed up because 15k over two
| months is too high or too low. It's squarely in the: "nobody
| has actually defined the project territory" for me.
|
| Yes, a Wordpress solution would work, but then why even
| budget 2 months for it, unless bespoke design is involved.
| Again that becomes a: this is too low or too high to be
| realistic
| notatoad wrote:
| >At no point is it clear that they've discussed off the
| shelf solutions, or infrastructure (storage, server hiding,
| CDN etc).
|
| why should they? the requirements are listed in the
| article. the job is to meet the requirements. "where should
| we store the files" is a job the client hires you to
| answer, not something requiring communication.
| dagmx wrote:
| The requirements are insufficient if you're going to be
| so particular as to stick exactly to them. You can't
| guarantee the uptime's requested without talking about
| infrastructure.
| [deleted]
| Aerbil313 wrote:
| Ted Kaczynski's "surrogate activities" term is very relevant
| here.
| allenu wrote:
| I absolutely agree with the premise. People just love building
| things even when they're not needed. After a while, your ego gets
| attached to whatever it is you've built and you can't let it go.
|
| I remember working at one place where somebody built a new
| framework to solve a common problem we all had. He pitched it to
| all the other devs in a meeting and I remember being confused
| about it because there was a standard framework that solved the
| problem already and did it in much simpler and more elegant way.
| (To be fair to him, this standard functionality was only recently
| introduced.)
|
| During his presentation, I asked why the standard solution
| wouldn't work for him. It turns out he wasn't familiar with it.
| Fair enough, so later I messaged him and showed him the standard
| way to do it and how much simpler it was. He couldn't be swayed.
|
| He just couldn't accept that his complicated solution wasn't
| necessary. He constructed scenarios where his idea was needed,
| even though I saw solutions to those scenarios using the standard
| framework.
|
| Interestingly enough, one of the scenarios where his custom thing
| was needed was in some tests he had written where he did some
| complicated things to set things up. I looked at the tests and
| even there saw those complicated things weren't necessary! There
| were ways to simplify what he was doing so that the tests were
| better written _and_ didn 't need his custom tool.
|
| Anyway, he wouldn't be convinced. And because he couldn't be
| convinced, we got stuck with his solution and saw people continue
| to work on it, add more functionality to it, fix bugs, etc. All
| of that work was just a waste of time when we could've relied on
| a standard solution, which was way more mature and way simpler.
|
| All of this drove me crazy, but I realized that sometimes people
| are just unable to see simple solutions to problems. Worse,
| having one complex solution begets more complex solutions
| elsewhere.
| manmal wrote:
| > people are just unable to see simple solutions to problems
|
| This person might just have been terrified of admitting that
| all the (very tangible) time they spent on payroll building
| this thing was for naught. It's unclear how their manager might
| have responded to that. And they wouldn't have been able to put
| ,,built system doing X used by Y developers and deployed to Z
| customers" in their resume.
|
| The reasonable choice often doesn't have much skin in the game.
| pydry wrote:
| Your guy clearly had an emotional attachment to his work not an
| inexplicable intellectual attachment.
|
| It's hard to admit that your baby is ugly.
| allenu wrote:
| You're right. It's a good lesson to take away when it isn't
| you because when you're that guy, it's so hard to separate
| yourself from your work.
| physicsguy wrote:
| This is one reason I'm glad I came from a research background
| into software. If something doesn't work it doesn't upset me
| and I don't personally feel aggrieved, you just chalk it up
| to experience and move on. The number of times I worked on a
| study that had to be abandoned either because it didn't work
| or because another research group beat us to it!
| bsaul wrote:
| this is definitely one of the advice i give to senior dev i work
| with: if you're proud of how smart your solution is, there's a
| high chance you overengineered and made a mess of a simple
| problem.
|
| i now take great pride when my code looks boringly obvious.
| [deleted]
| MajimasEyepatch wrote:
| Related: my favorite pull requests are the ones that remove
| more lines of code than they add. People think you need to
| hoard old code that's not used anymore like it's made of gold.
| It's not. You aren't gonna need it, and if you do, you can find
| it in the git history.
| sopooneo wrote:
| I push that so hard. Put the removal in an isolated, clearly
| named commit that will be easy to search later, tag that
| commit so it never gets garbage collected, then take a deep
| breath and say goodbye.
|
| You'll be better off without it and 99.9% of the time you
| won't have to retrieve it later anyway.
| Daniel_sk wrote:
| Antoine de Saint-Exupery -- 'Perfection is achieved, not when
| there is nothing more to add, but when there is nothing left
| to take away.'
| stevehind wrote:
| This resonates and one way to describe it is an incentive
| problem. Someone whose incentives are _tightly_ aligned with the
| business is going to solve the actual problem and simply and
| effectively as possible. Someone who is incentivized to build
| career capital and experience other than via impact (e.g. so they
| can get uplevelled, pass an external interview loop, etc) is much
| more likely to focus on unimportant hard problems and /or over
| engineer.
| djbusby wrote:
| RDD: Resume Driven Development
| jiggawatts wrote:
| In a large government IT department:
|
| "I think we should use a Kubernetes cluster!"
|
| "You're joking, surely? This is a tiny web site with mostly
| static content!"
|
| Next project:
|
| "For this web app, I propose we use Kubernetes..."
| f1shy wrote:
| I will take that!!!
| noirbot wrote:
| This is absolutely a thing, but I'd say there's a related
| option which is "Job Listing Driven Development". The more
| niche, dated, or specific your platform is, the harder it is
| to hire people onto the team who don't need months of on-the-
| job practice and training to be useful.
|
| You see the most extreme versions of dangers of this in
| stories about governments and older companies having to pay
| insane salaries to bring FORTRAN or COBOL developers out of
| retirement to keep systems running. If you keep doing the
| simple solutions within the existing system, you risk
| creating a system so inbred that only the folks who built it
| can maintain it effectively.
|
| For less extreme setups, it's still a balancing act to
| consider how much your unique and specific solution that is
| the simple option for you company starts closing you off of
| the larger hiring pools in more common technologies and
| patterns.
| BeFlatXIII wrote:
| What's kind of funny is that MUMPS is equally as archaic
| and idiosyncratic as Fortran or Cobol, yet there are
| companies willing to put new hires through a bootcamp to
| make them productive. Are all the Fortran and Cobol
| companies too small to afford a month or three of training
| time on new devs?
| wfhBrian wrote:
| And thus we will see the rise of the software solopreneur.
| Gareth321 wrote:
| That's been a thing for 30 years. Entrepreneurship is HARD,
| and tech salaries are fat right now. I think we'll see a lot
| more software entrepreneurship when there's another
| recession.
| UweSchmidt wrote:
| Makes you wonder what the actual state of the industry is
| right now with thousands of layoffs, but then comments like
| this one. Probably it's a bifurcation and an uneven
| distribution of reality.
| David_SQOX wrote:
| You hit the nail on the head. There are different motivations
| for different roles within the same company, sometimes those
| motivations clash internally, all the while each individual IS
| acting completely logically from their own unique perspectives.
| noirbot wrote:
| Doing the sort of simple solutions to your specific job's
| actual problems can also be something that constrains your
| ability to work anywhere else. Often the best simple solution
| that's tightly integrated into your job's environment is
| something that is inconceivable as a good idea anywhere else.
| You're optimizing around other old decisions, good or bad.
| You're often correctly overfitting a solution to your specific
| problems.
|
| I've often found myself now having issues even updating my
| resume, because what I did for the last year at work barely is
| explainable to other people on my team, let alone to someone in
| HR at another company. Or the more simple explanation is
| something that sounds like I'm doing work barely more complex
| than an intern could have done. Which often isn't wrong, but
| the intern wouldn't know _which_ simple work to do.
|
| My years of experience in the company's stack and org is
| valuable to the company, and nontransferable elsewhere.
| neon_electro wrote:
| I share this problem in the last year+ of job searching I've
| been up to.
| jayd16 wrote:
| I don't think its just an incentive problem only. I know plenty
| of engineers doing premature optimization or scope creep in
| good faith.
| bob1029 wrote:
| > Someone whose incentives are tightly aligned with the
| business is going to solve the actual problem and simply and
| effectively as possible.
|
| Equity is the entirely the answer for cutting through all the
| bullshit. At least in my head. I don't know how it plays in
| other people's minds but mine sounds like: "If we ship and go
| live, I get x% of all profit moving forward in my personal
| scrooge mcduck money bin". Pretty big carrot. It's kind of like
| time share in my own personal business, but I don't have much
| of the headache that goes along with running my own 100%.
|
| This has some caveats, namely that equity in a 10k person org
| is often times not nearly as meaningful as equity in a 10
| person org. Shipping your code 2 weeks early at Ford or Dell
| means what, exactly? If the code you are shipping _is_ the
| business, then things are different. It also really helps if
| you care about the problem you are solving.
|
| I'd say this - if the idea of direct equity/ownership doesn't
| get you _excited_ about pushing simple & robust techniques,
| then you are completely in the wrong place. You should probably
| find a different problem space or industry to work in.
| Hollywood might be a better option if the notion of equity or
| straight ownership in the business still isn't enough to put
| your tech ego into a box.
| smfjaw wrote:
| Equity is the answer, I work in investment banking and we all
| get a share of firm profits, I'll often sideline small
| projects in favour of projects that I think will be more
| valuable to the org and increase my/our pay cheque come bonus
| time
| ThalesX wrote:
| I have a little bit of equity in the company that I work for
| now. It's super small and early stage, and still between me
| and the product decision there exists a Designer that reports
| to a CTO that reports to a CEO. For everything that I want to
| see done differently, I have to make a case that convinces
| all these stakeholders that it's the right way. Ultimately,
| equity or not, my job is to row the ship where the cap'n
| tells me.
| TuringNYC wrote:
| >> Equity is the entirely the answer for cutting through all
| the bullshit.
|
| I agree for small companies which are largely founder owned.
| I think outside of that, Equity doesnt do much because so
| much effort is put into obfuscating the value/share of the
| equity. If you cant see the cap table, and you cant see the
| preference overhang, the equity is as good as worth zero.
| There is no discernable value for a fraction with no
| denominator.
| l0b0 wrote:
| > Someone whose incentives are tightly aligned with the
| business is going to solve the actual problem and simply and
| effectively as possible.
|
| _On average,_ and depending on skill. Incentives are hugely
| important (probably the most important metric any manager could
| work on), but even they do not guarantee results. If you hire
| so many juniors that nobody is there to upskill them _fast,_
| you only get one lottery ticket per employee. Conversely, if
| you hire a bunch of geniuses and fail to give them incentives
| to work on realisable, useful problems _together,_ you get two
| lottery tickets per employee at twice the price.
|
| (This comment feels woefully incomplete. Does anyone know of
| good resources to learn more about incentive structures and how
| they relate to individual and company success? I feel like the
| problem is that incentive structures change massively when
| companies grow, so even for unicorns there's just a short sweet
| spot where we can actually learn how they are supposed to
| look.)
___________________________________________________________________
(page generated 2023-06-18 23:00 UTC)