7 ms·

> For agency work building disposable marketing sites Funny, because I did some freelancing work fixing disposable vibe-coded landing pages recently. And if th

by whstl 1y ago

> For agency work building disposable marketing sites Funny, because I did some freelancing work fixing disposable vibe-coded landing pages recently. And if there's one thing we can count on is that the biggest control-freaks will always have that one extra stupid requirement that completely befuddles the AI and pushes it into making an even bigger mess, and then I'll have to come fix it. It doesn't matter how smart the AI becomes, the problems we face with software are rarely technical. The problem is always the people creating accidental complexity and pushing it to the next person as if it was "essential". The biggest asset of a developer is saying "no" to people. Perhaps AIs will learn that, but with competing AIs I'm pretty sure we'll always get one or the other to say yes, just like we have with people.

jvanderbot 1y ago
There's a whole book about this called people ware. It's why I'm fond of saying "may all your problems be technical". It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.
- whstl 1y ago
  Yep. With a good enough team, even the technical problems are almost 100% caused by people issues.
  - osigurdson 1y ago
    I've heard this many times. It isn't clear what it means however. If nearly 100% of problems are "people problems", what are some examples of "people solutions"? That may help clarify.
    - whstl 1y ago
      Keep in mind I said "with a good enough team". "People problems" are problems mainly caused by lack of design consistency, bad communication, unclear vision, micromanagement. A "people solution" would be to, instead of throwing crumbs to the developers, actually have a shared vision that allows the developers/designers/everyone to plan ahead, produce features without fear (causing over-engineering) or lack of care (causing under-engineering). Even if there is no plan other than "go to market ASAP", everyone should be aware of it and everyone should be aware of the consequences of swerving the car 180 degrees at 100km/h. Feedback both ways is important, because if you only have top-down communication, the only feedback will be customer complaints and developers getting burned out.
      - Espressosaurus 1y ago
        I would generalize micromanagement to "bad management". I have been empowered to do things but what I was doing was attempting to clean up in software hardware that sucked because it was built in-house instead of using the well-made external part, and on a schedule that didn't permit figuring out how to build the thing right. 100% management-induced problems.
        whstl 1y ago
        Another issue is when micromanagement gets in the way of transmitting importing information, it becomes more than a nuisance :/
        ghaff 1y ago
        Building things in house rather than buying something that is close enough is hardly uniquely a management failing.
      - osigurdson 1y ago
        Are "people problems" essentially "leadership / vision problems" in your view?
        whstl 1y ago
        The cause might not be a leader (cross functional teams are rife with such problems), but the leader has the responsibility to deal with it, so I guess it is…
    - jvanderbot 1y ago
      The book mentioned, "Peopleware" is probably your best resource, it's short. But sibling comment is also right on.
  - bcrosby95 1y ago
    Technical problems are what cause the people problems though. You can't completely blame one or the other.
    - whstl 1y ago
      People problems happen way before the first line of code is written, even when there's not even a single engineer in the vicinity, even when the topic is not remotely related to engineering.
xnickb 1y ago
This is actually a very good point. Although it's indeed not hard to imagine AI being far better at estimating the complexity of a potential solution and warning the user about it. For example in chess AI is already far better than humans. Including on tasks like evaluating positions. Admittedly, I use "AI" in a broad sense here, despite the article being mostly focused on LLMs.
Lutger 1y ago
Between "no" and "yes sure" also lie 50 shades of "is this what you meant?". For example, this older guy asked me to create a webpage where people could "download the database". He meant a very limited csv export of course. I an wondering if chatgpt would have understood his prompts, and this was one of the more obvious ones to me.
- whstl 1y ago
  Definitely. Saying no is not really denying, it's negotiating.
  - blooalien 1y ago
    > Saying no is not really denying, it's negotiating. Sometimes. I have often had to say "no" because the customer request is genuinely impossible. Then comes the fun bit of explaining why the thing they want simply cannot exist, because often they'll try "But what if you just ... ?" – "No! It doesn't work that way, and here's why..."
    - whstl 1y ago
      Argh. I had to explain recently that `a * x !== b * x when a !== b`*... it is infuriating hearing "but the result is the same in this other competitor" coupled with the "maybe the problem here is you're not knowledgeable enough to understand".
      - cogman10 1y ago
        Ah, I see you've worked on financial software as well ;) We've definitely had our fair share of "IDK what to tell you, those guys are mathing wrong". TBF, though, most customers are pretty tolerant of explainable differences in computed values. There's a bunch of "meh, close enough" in finance. We usually only run into the problem when someone (IMO) is looking for a reason not to buy our software. "It's not a perfect match, no way we can use this" sort of thing.
mjlangiii 1y ago
I agree, a stark difference between AI and me is knowing when to say, "no", and/or to dig deeper for the unspoken story/need/value.
fridder 1y ago
Other than saying no, the other asset is: "I see where this is going and how the business is going so I better make it flexible/extensible in X way so the next bit is easier."
- pseudocomposer 1y ago
  This does assume the direction you see is accurate, which I’d argue heavily depends on communication skills.
brookst 1y ago
Excellent reformulation of the classic “requirement bug”: software can be implemented perfectly, but if the requirements don’t make sense including accounting for the realities of the technical systems, mayhem ensues. I think AI will get there when it comes to “you asked for a gif but they don’t support transparency”, but I am 100% sure people will continue to write “make the logo a square where every point is equidistant from the center” requirments. EDIT: yes jpg, not gif, naughty typo + autocorrect
- staunton 1y ago
  > people will continue to write “make the logo a square where every point is equidistant from the center” requirments. Why wouldn't the AI deal with that the same way human developers do? Follow up with questions, or iterate requirements?
  - AlotOfReading 1y ago
    Go ahead and try it with your favorite LLMs. They're too deferential to push back consistently or set up a dialectic and they struggle to hold onto lists of requirements reliably.
    - staunton 1y ago
      I'm not saying they can do it today. I'm saying there's no ruling out they might be able to do it soon.
      - Avicebron 1y ago
        That'll be rough, when you go on your computer and you tell it to do a thing and it just says "no, ur dumb".... not sure we want that
        fzzzy 1y ago
        Doesn't matter if you want it or not, it's going to be available, because only an llm that can do that will be useful for actual scientific discovery. Individuals that wish to do actual scientific discovery will know the difference, because they will test the output of the llm. [edit] In other words, llms that lie less will be more valuable for certain people, therefore llms that tell you when you are dumb will eventually win in those circles, regardless of how bruising it is to the user's ego.
romec 1y ago
It is always the case that an expert doesn't just have to be good at things, they also have to not be bad at them. Saying no to doing things they are bad at is part of that. But it doesn't matter. We can argue that AI can do this or that, or that it can't do this or that. But what is the alternative that is better? There often isn't one. We have already been through this repeatedly in areas such as cloud computing. Running you own servers is leaner, but then you have to acquire servers, data centers and operations. Which is hard. While cloud computing has become easy. In another story here there are many defending that HN is simple [0]. Then it is noted that it might be getting stale [1]. Unsurprisingly as the simple nature of HN doesn't offer much over asking an LLM. There are things an LLM can't do, but HN doesn't do much of that. For people to be better we actually need people. Who have housing, education and healthcare. And good technologies that can deliver performance, robustness and security. But HN is full of excuses why those things aren't needed, and that is something that AI can match. And it doesn't have to be that good to do it. [0] https://news.ycombinator.com/item?id=44099357 https://news.ycombinator.com/item?id=44099357 [1] https://news.ycombinator.com/item?id=44101473 https://news.ycombinator.com/item?id=44101473
- mattgreenrocks 1y ago
  > HN is full of excuses why those things aren't needed, and that is something that AI can match It's not just on HN; there's a lot of faith in the belief that eventually AI will enable enlightened individuals infinite leverage that doesn't hinge on pesky Other People. All they need to do is trust the AI, and embrace the exponentials. Calls for the democratization of art also fall under this. Part of what develops one's artistic taste is the long march of building skills, constantly refining, and continually trying to outdo yourself. In other words: The Work. If you believe that only the output matters, then you're missing out on the journey that confers your artistic voice. If people had felt they had sufficient leverage over their own lives, they wouldn't need to be praying to the machine gods for it. That's a much harder problem for sure. But I don't see AI solving that.
evantbyrne 1y ago
Agency work seems to be a blind spot for individuals within the startup world, with many not realizing that it goes way beyond theme chop shops. The biggest companies on the planet not only contract with agencies all the time, external contractors do some of their best work. e.g., Huge has won 3 Webby awards for Google products.
- whstl 1y ago
  Oh I agree. I don't really have a problem with agencies, the topic of them is not really related to my reply. My focus was more on the "disposable" part.
JeremyNT 1y ago
> The biggest asset of a developer is saying "no" to people. Perhaps AIs will learn that, but with competing AIs I'm pretty sure we'll always get one or the other to say yes, just like we have with people. In my experience this is always the hardest part of the job, but it's definitely not what a lot of developers enjoy (or even consider to be their responsibility). I think it's true that there will always be room for developers-who-are-also-basically-product-managers, because success for a lot of projects will boil down to really understanding the stakeholders on a personal level.
- suzzer99 1y ago
  Saying no is the hardest part of the job, and it's only possible after you've been around a few years and already delivered a lot of value. There's also an art to it in how you frame the response, figuring out what the clients really want, and coming up with something that gets them 90% there w/o mushrooming app complexity. Good luck with AI on that.
- bicx 1y ago
  I think the biggest skill I've developed is the "Yes, but..." Japanese style of saying "no" without directly saying "no." Essentially you're saying anything is possible, but you may need to expand restraints (budget, time, complexity). If your company culture expects the engineering team to evaluate and have an equal weight into making feature decisions, then a flat "no" is more acceptable. If you're in a non-tech-first company like I am, simply saying "no" makes _you_ look like the roadblock unless you give more context and allow others to weigh in on what they're willing to pay.
  - suzzer99 1y ago
    We merged with a group from Israel and I had to explain to them that our engineers had given them the "Hollywood no" on something they'd asked for. Basically "Yes, that sounds like a great idea" which actually means "Hell no" unless it's immediately followed up with an actionable path forward. The Israeli engineers found this very amusing and started asking if it was really a Hollywood no anytime they'd get a yes answer on something.
davidw 1y ago
As an aside, where does one look for freelancing work these days? Besides word of mouth.
- dgb23 1y ago
  With the risk of giving you a non-answer: In my personal experience there’s no substitute to building relationships if you’re an individual or small company looking for contract/freelance work. It starts slow, but when you’re doing good work and maintain relationships you‘ll be swimming in work eventually.
  - whstl 1y ago
    OP here. That's the answer I was gonna give... most of the freelancing work I did was via personal relationships. Often personal relationships with companies that employed me in the past, or companies where ex-colleagues worked. The only single time I did freelance work for anyone else was when my neighbour (a graphic designer) sent some work my way.
BurningFrog 1y ago
Just saying "no" isn't helpful for anyone. Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performance. This leads to a conversation that enlightens both parties. It may even result in you understanding why and how the request is good after all.
- setr 1y ago
  Seconding this. With infinite time and money, I can do whatever you want — excepting squaring the circle. Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match. Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process. It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it
- brandall10 1y ago
  Some years back I took on a embattled project, a dispenser/retriever for scrubs in a hospital environment that had a major revision stuck in dev hell for over 2 years. After auditing the state of the work I decided to discard everything. After that, we started with a clean slate of over 200 bugs w/ 45 features to be developed. Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5. Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.
taco_emoji 1y ago
> ...will always have that one extra stupid requirement that completely befuddles the AI and pushes it into making an even bigger mess, and then I'll have to come fix it. Finally, a Microsoft FrontPage for the 2020's
helge9210 1y ago
> biggest control-freaks "control-freak" not necessary. For any known sequence/set of feature requirements it is possible to choose an optimal abstraction. It's also possible to order the requirements in such a way, that introduction of next requirement will entirely invalidate an abstraction, chosen for the previously introduced requirements. Most of the humans have trouble recovering from such a case. Those who do succeed are called senior software engineers.
frausto 1y ago
great quote: > the problems we face with software are rarely technical. The problem is always the people creating accidental complexity and pushing it to the next person as if it was "essential" Until a level of absolutely massive scale, modern tooling and code and systems reasonably built can handle most things technically, so it usually comes down to minimizing complexity as the #1 thing you can do to optimize development. And that could be - code design complexity - design complexity - product complexity - communication complexity - org complexity And sometimes minimizing these ARE mutually exclusive (most times not, and in an ideal world never… but humans...) which is why much of our job is to all push back and trade off against complexity in order to minimize it. With the understanding that there are pieces of complexity so inherent in a person/company/code/whatever’s processes that in the short term you learn to work around/with it in order to move forward at all, but hopefully in the long term make strategic decisions along the way to phase it out
robocat 1y ago
> accidental complexity Haven't we found a better term for that yet? It is intentional, designed complexity... There's no accident about it: engineers or management chose it. Recent discussion on accidental versus essential (kicked off by a flagged article): https://news.ycombinator.com/item?id=44090302 https://news.ycombinator.com/item?id=44090302 (choosing good dichotomies is difficult, since there's always exceptions to both categories)
- whstl 1y ago
  You can call it non-essential complexity. I don’t really care for the name but I care about grifters pretending it doesn’t really exist.
deleted 1y ago
[deleted]

by whstl 1y ago

jvanderbot 1y ago

There's a whole book about this called people ware. It's why I'm fond of saying "may all your problems be technical". It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.

whstl 1y ago
Yep. With a good enough team, even the technical problems are almost 100% caused by people issues.
- osigurdson 1y ago
  I've heard this many times. It isn't clear what it means however. If nearly 100% of problems are "people problems", what are some examples of "people solutions"? That may help clarify.
  - whstl 1y ago
    Keep in mind I said "with a good enough team". "People problems" are problems mainly caused by lack of design consistency, bad communication, unclear vision, micromanagement. A "people solution" would be to, instead of throwing crumbs to the developers, actually have a shared vision that allows the developers/designers/everyone to plan ahead, produce features without fear (causing over-engineering) or lack of care (causing under-engineering). Even if there is no plan other than "go to market ASAP", everyone should be aware of it and everyone should be aware of the consequences of swerving the car 180 degrees at 100km/h. Feedback both ways is important, because if you only have top-down communication, the only feedback will be customer complaints and developers getting burned out.
    - Espressosaurus 1y ago
      I would generalize micromanagement to "bad management". I have been empowered to do things but what I was doing was attempting to clean up in software hardware that sucked because it was built in-house instead of using the well-made external part, and on a schedule that didn't permit figuring out how to build the thing right. 100% management-induced problems.
      - whstl 1y ago
        Another issue is when micromanagement gets in the way of transmitting importing information, it becomes more than a nuisance :/
      - ghaff 1y ago
        Building things in house rather than buying something that is close enough is hardly uniquely a management failing.
    - osigurdson 1y ago
      Are "people problems" essentially "leadership / vision problems" in your view?
      - whstl 1y ago
        The cause might not be a leader (cross functional teams are rife with such problems), but the leader has the responsibility to deal with it, so I guess it is…
  - jvanderbot 1y ago
    The book mentioned, "Peopleware" is probably your best resource, it's short. But sibling comment is also right on.
- bcrosby95 1y ago
  Technical problems are what cause the people problems though. You can't completely blame one or the other.
  - whstl 1y ago
    People problems happen way before the first line of code is written, even when there's not even a single engineer in the vicinity, even when the topic is not remotely related to engineering.

xnickb 1y ago

This is actually a very good point. Although it's indeed not hard to imagine AI being far better at estimating the complexity of a potential solution and warning the user about it. For example in chess AI is already far better than humans. Including on tasks like evaluating positions. Admittedly, I use "AI" in a broad sense here, despite the article being mostly focused on LLMs.

Lutger 1y ago

Between "no" and "yes sure" also lie 50 shades of "is this what you meant?". For example, this older guy asked me to create a webpage where people could "download the database". He meant a very limited csv export of course. I an wondering if chatgpt would have understood his prompts, and this was one of the more obvious ones to me.

whstl 1y ago
Definitely. Saying no is not really denying, it's negotiating.
- blooalien 1y ago
  > Saying no is not really denying, it's negotiating. Sometimes. I have often had to say "no" because the customer request is genuinely impossible. Then comes the fun bit of explaining why the thing they want simply cannot exist, because often they'll try "But what if you just ... ?" – "No! It doesn't work that way, and here's why..."
  - whstl 1y ago
    Argh. I had to explain recently that `a * x !== b * x when a !== b`*... it is infuriating hearing "but the result is the same in this other competitor" coupled with the "maybe the problem here is you're not knowledgeable enough to understand".
    - cogman10 1y ago
      Ah, I see you've worked on financial software as well ;) We've definitely had our fair share of "IDK what to tell you, those guys are mathing wrong". TBF, though, most customers are pretty tolerant of explainable differences in computed values. There's a bunch of "meh, close enough" in finance. We usually only run into the problem when someone (IMO) is looking for a reason not to buy our software. "It's not a perfect match, no way we can use this" sort of thing.

mjlangiii 1y ago

I agree, a stark difference between AI and me is knowing when to say, "no", and/or to dig deeper for the unspoken story/need/value.

fridder 1y ago

Other than saying no, the other asset is: "I see where this is going and how the business is going so I better make it flexible/extensible in X way so the next bit is easier."

pseudocomposer 1y ago
This does assume the direction you see is accurate, which I’d argue heavily depends on communication skills.

brookst 1y ago

Excellent reformulation of the classic “requirement bug”: software can be implemented perfectly, but if the requirements don’t make sense including accounting for the realities of the technical systems, mayhem ensues. I think AI will get there when it comes to “you asked for a gif but they don’t support transparency”, but I am 100% sure people will continue to write “make the logo a square where every point is equidistant from the center” requirments. EDIT: yes jpg, not gif, naughty typo + autocorrect

staunton 1y ago
> people will continue to write “make the logo a square where every point is equidistant from the center” requirments. Why wouldn't the AI deal with that the same way human developers do? Follow up with questions, or iterate requirements?
- AlotOfReading 1y ago
  Go ahead and try it with your favorite LLMs. They're too deferential to push back consistently or set up a dialectic and they struggle to hold onto lists of requirements reliably.
  - staunton 1y ago
    I'm not saying they can do it today. I'm saying there's no ruling out they might be able to do it soon.
    - Avicebron 1y ago
      That'll be rough, when you go on your computer and you tell it to do a thing and it just says "no, ur dumb".... not sure we want that
      - fzzzy 1y ago
        Doesn't matter if you want it or not, it's going to be available, because only an llm that can do that will be useful for actual scientific discovery. Individuals that wish to do actual scientific discovery will know the difference, because they will test the output of the llm. [edit] In other words, llms that lie less will be more valuable for certain people, therefore llms that tell you when you are dumb will eventually win in those circles, regardless of how bruising it is to the user's ego.

romec 1y ago

It is always the case that an expert doesn't just have to be good at things, they also have to not be bad at them. Saying no to doing things they are bad at is part of that. But it doesn't matter. We can argue that AI can do this or that, or that it can't do this or that. But what is the alternative that is better? There often isn't one. We have already been through this repeatedly in areas such as cloud computing. Running you own servers is leaner, but then you have to acquire servers, data centers and operations. Which is hard. While cloud computing has become easy. In another story here there are many defending that HN is simple [0]. Then it is noted that it might be getting stale [1]. Unsurprisingly as the simple nature of HN doesn't offer much over asking an LLM. There are things an LLM can't do, but HN doesn't do much of that. For people to be better we actually need people. Who have housing, education and healthcare. And good technologies that can deliver performance, robustness and security. But HN is full of excuses why those things aren't needed, and that is something that AI can match. And it doesn't have to be that good to do it. [0] https://news.ycombinator.com/item?id=44099357 https://news.ycombinator.com/item?id=44099357 [1] https://news.ycombinator.com/item?id=44101473 https://news.ycombinator.com/item?id=44101473

mattgreenrocks 1y ago
> HN is full of excuses why those things aren't needed, and that is something that AI can match It's not just on HN; there's a lot of faith in the belief that eventually AI will enable enlightened individuals infinite leverage that doesn't hinge on pesky Other People. All they need to do is trust the AI, and embrace the exponentials. Calls for the democratization of art also fall under this. Part of what develops one's artistic taste is the long march of building skills, constantly refining, and continually trying to outdo yourself. In other words: The Work. If you believe that only the output matters, then you're missing out on the journey that confers your artistic voice. If people had felt they had sufficient leverage over their own lives, they wouldn't need to be praying to the machine gods for it. That's a much harder problem for sure. But I don't see AI solving that.

evantbyrne 1y ago

Agency work seems to be a blind spot for individuals within the startup world, with many not realizing that it goes way beyond theme chop shops. The biggest companies on the planet not only contract with agencies all the time, external contractors do some of their best work. e.g., Huge has won 3 Webby awards for Google products.

whstl 1y ago
Oh I agree. I don't really have a problem with agencies, the topic of them is not really related to my reply. My focus was more on the "disposable" part.

JeremyNT 1y ago

> The biggest asset of a developer is saying "no" to people. Perhaps AIs will learn that, but with competing AIs I'm pretty sure we'll always get one or the other to say yes, just like we have with people. In my experience this is always the hardest part of the job, but it's definitely not what a lot of developers enjoy (or even consider to be their responsibility). I think it's true that there will always be room for developers-who-are-also-basically-product-managers, because success for a lot of projects will boil down to really understanding the stakeholders on a personal level.

suzzer99 1y ago
Saying no is the hardest part of the job, and it's only possible after you've been around a few years and already delivered a lot of value. There's also an art to it in how you frame the response, figuring out what the clients really want, and coming up with something that gets them 90% there w/o mushrooming app complexity. Good luck with AI on that.
bicx 1y ago
I think the biggest skill I've developed is the "Yes, but..." Japanese style of saying "no" without directly saying "no." Essentially you're saying anything is possible, but you may need to expand restraints (budget, time, complexity). If your company culture expects the engineering team to evaluate and have an equal weight into making feature decisions, then a flat "no" is more acceptable. If you're in a non-tech-first company like I am, simply saying "no" makes _you_ look like the roadblock unless you give more context and allow others to weigh in on what they're willing to pay.
- suzzer99 1y ago
  We merged with a group from Israel and I had to explain to them that our engineers had given them the "Hollywood no" on something they'd asked for. Basically "Yes, that sounds like a great idea" which actually means "Hell no" unless it's immediately followed up with an actionable path forward. The Israeli engineers found this very amusing and started asking if it was really a Hollywood no anytime they'd get a yes answer on something.

davidw 1y ago

As an aside, where does one look for freelancing work these days? Besides word of mouth.

dgb23 1y ago
With the risk of giving you a non-answer: In my personal experience there’s no substitute to building relationships if you’re an individual or small company looking for contract/freelance work. It starts slow, but when you’re doing good work and maintain relationships you‘ll be swimming in work eventually.
- whstl 1y ago
  OP here. That's the answer I was gonna give... most of the freelancing work I did was via personal relationships. Often personal relationships with companies that employed me in the past, or companies where ex-colleagues worked. The only single time I did freelance work for anyone else was when my neighbour (a graphic designer) sent some work my way.

BurningFrog 1y ago

Just saying "no" isn't helpful for anyone. Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performance. This leads to a conversation that enlightens both parties. It may even result in you understanding why and how the request is good after all.

setr 1y ago
Seconding this. With infinite time and money, I can do whatever you want — excepting squaring the circle. Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match. Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process. It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it
brandall10 1y ago
Some years back I took on a embattled project, a dispenser/retriever for scrubs in a hospital environment that had a major revision stuck in dev hell for over 2 years. After auditing the state of the work I decided to discard everything. After that, we started with a clean slate of over 200 bugs w/ 45 features to be developed. Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5. Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.

taco_emoji 1y ago

> ...will always have that one extra stupid requirement that completely befuddles the AI and pushes it into making an even bigger mess, and then I'll have to come fix it. Finally, a Microsoft FrontPage for the 2020's

helge9210 1y ago

> biggest control-freaks "control-freak" not necessary. For any known sequence/set of feature requirements it is possible to choose an optimal abstraction. It's also possible to order the requirements in such a way, that introduction of next requirement will entirely invalidate an abstraction, chosen for the previously introduced requirements. Most of the humans have trouble recovering from such a case. Those who do succeed are called senior software engineers.

frausto 1y ago

great quote: > the problems we face with software are rarely technical. The problem is always the people creating accidental complexity and pushing it to the next person as if it was "essential" Until a level of absolutely massive scale, modern tooling and code and systems reasonably built can handle most things technically, so it usually comes down to minimizing complexity as the #1 thing you can do to optimize development. And that could be - code design complexity - design complexity - product complexity - communication complexity - org complexity And sometimes minimizing these ARE mutually exclusive (most times not, and in an ideal world never… but humans...) which is why much of our job is to all push back and trade off against complexity in order to minimize it. With the understanding that there are pieces of complexity so inherent in a person/company/code/whatever’s processes that in the short term you learn to work around/with it in order to move forward at all, but hopefully in the long term make strategic decisions along the way to phase it out

robocat 1y ago

> accidental complexity Haven't we found a better term for that yet? It is intentional, designed complexity... There's no accident about it: engineers or management chose it. Recent discussion on accidental versus essential (kicked off by a flagged article): https://news.ycombinator.com/item?id=44090302 https://news.ycombinator.com/item?id=44090302 (choosing good dichotomies is difficult, since there's always exceptions to both categories)

whstl 1y ago
You can call it non-essential complexity. I don’t really care for the name but I care about grifters pretending it doesn’t really exist.

deleted 1y ago

[deleted]