[HN Gopher] Manifesto for minimalist software engineers (2013)
___________________________________________________________________
Manifesto for minimalist software engineers (2013)
Author : fabianholzer
Score : 141 points
Date : 2022-11-07 07:50 UTC (15 hours ago)
(HTM) web link (minifesto.org)
(TXT) w3m dump (minifesto.org)
| numeromancer wrote:
| Cf. https://suckless.org/philosophy/
| markuman123 wrote:
| no valid https ...
| [deleted]
| [deleted]
| [deleted]
| adql wrote:
| Looking forward to time when that manifesto will be used as
| excuses for bad design decisions and treated as silver bullet,
| just like every previous one
|
| Also
|
| >88 requests, 2.1MB transferred 5.4MB resources, finish 9.04s
|
| Practice what you preach maybe ?
| hbogert wrote:
| the majority of it being discus/twitter/etc. Is that his fault?
| At least he didn't reinvent a forum, so in that sense it is
| minimal.
| TeMPOraL wrote:
| > _At least he didn 't reinvent a forum, so in that sense it
| is minimal._
|
| Herein lies the problem though: it's "minimal" for them, at
| the expense of the users. Like all those soundbites.
| [deleted]
| andai wrote:
| Destroy the child!
| revskill wrote:
| I think this misses one of the most crucial one: Prove it.
| forgotmypw17 wrote:
| Ironically, the markup for this site is not minimalist at all.
| [deleted]
| golf_mike wrote:
| But at least they kept their ssl implementation simple
| forgotmypw17 wrote:
| SSL is hardly minimal
| sorokod wrote:
| Which part of this is specific to software engineering?
| prideout wrote:
| I don't understand the "sedimentation" item. How does
| "accumulating other bugs" cause a bug to go away?
| hliyan wrote:
| When considering killing the baby, also be aware that complex
| systems that work, almost always evolve from simple systems that
| work. A complex system can rarely be developed from the ground up
| (i.e. via a rewrite). One may then interpret the above maxim as
| "kill your code while it's still a baby, not once it reaches
| adulthood".
| marban wrote:
| Please stop the MVP, fail fast, etc. garbage. It's the stage
| where winners are made. 99% of projects won't sell themselves and
| you will only end up with the self-pleasing excuse that your idea
| was flawed when in reality, you've sucked at marketing.
|
| Bonus: It's 2022 and people are no longer interested in playing
| with half-baked MVPs. Think twice before skimping on a decent UI,
| etc. There won't be a second chance to make a first impression.
| brosinante wrote:
| I find the concept that my ideas are not flawed (and how dare
| anyone suggest they are) and success is a matter of connections
| and existing wealth more self pleasing.
| hahamrfunnyguy wrote:
| A MVP and quality product are not mutually exclusive. To me MVP
| means do a limited set of things and do them very well. UX is
| of course part of that.
|
| Failing fast and iterating is absolutely important to make sure
| you're building what your users actually need. I've found that
| what users want/need and what they think they want can be very
| different.
| [deleted]
| rolenthedeep wrote:
| Don't make minimalist software. Minimalist software is bad.
|
| Make software that _works_. Make software that people can _use_.
| Software is a _tool_ , not a goddamn modern art project.
| thefaux wrote:
| ^ bad
| [deleted]
| TurboHaskal wrote:
| Ah, the minimalist software engineer. I usually encounter them in
| PRs claiming a change is "over-engineered" despite being
| literally 5 LOC. It's such a comfortable position to label
| everything you don't understand as complex and unnecessary. Bonus
| points of you throw in YAGNI and KISS acronyms!
|
| I have a problem with "Perfect is enemy of good". I get the whole
| thing with iteration and so on, it looks good on paper, but in my
| experience when it comes to "First do it, then do it right, then
| do it better" and modern software development methodologies, you
| are lucky if you even get to work on the second step. And the
| nastiest projects I've encountered in my career have been all
| "evolved".
| [deleted]
| hbrn wrote:
| > you are lucky if you even get to work on the second step
|
| I've done over and over without any issues.
|
| In order to work on second step you need two things:
|
| 1. A plan (at least a vague one) of how will you execute the
| second step iteratively (i.e. without rewriting everything from
| scratch).
|
| 2. Actual business need for step 2.
|
| If you aren't able to execute step 2 without the Big Rewrite,
| then it's on you. Business doesn't want to take these risks.
|
| If your business doesn't need step 2, then what are we
| complaining about?
|
| I guess the only advice I have is stop treating step 2 as
| "step". It follows the same Pareto Principle: there's 20% of
| effort in step 2 which gives 80% of results.
| TurboHaskal wrote:
| > If your business doesn't need step 2, then what are we
| complaining about?
|
| Hacky, non automated, low quality, not tested, hard to
| maintain, slow code. Remember, we are at step 1 of "First do
| it, then do it right, then do it better."
|
| Business rarely needs refactorings and performance
| improvements, until they do, and things turns really ugly
| when they do, because they've been focusing on shipping "good
| enough" crap instead of focusing on the actual "continuous
| improvement" they claim to do.
| hbrn wrote:
| > Hacky, non automated, low quality, not tested, hard to
| maintain, slow code
|
| Have you seen truck drivers complaining they are forced to
| drive old trucks and not brand new Ferraris?
|
| If low quality code gets shit done, why would company
| invest into high quality? Delivering goods in Ferraris
| might be hell of a fun for drivers, but it's a stupid
| decision for a trucking company.
|
| How confident are you that your high quality will pay off?
| When exactly will it pay off? How confident are you that
| your measurement of "high quality" is not biased? How
| confident are you that your teammate's perception of "high
| quality" is not just chasing new hype?
|
| > Business rarely needs refactorings and performance
| improvements, until they do, and things turns really ugly
| when they do
|
| Sure, and that's why it's your job to prepare for it. Not
| by creating "high quality" code in advance, but by creating
| low quality code that is malleable.
| jrochkind1 wrote:
| "perfect" is the enemy of "good", but so is "bad". Bad is
| definitely the enemy of good.
|
| So it winds up being arguments about whether something is "bad"
| or "good enough". I mean, that's kind of the whole damn trick,
| figuring out what is good enough.
|
| It's good to remember that "good enough" has upper as well as
| lower bands, it's true that perfectionism is not the way to go
| -- especially because you are usually over-confident in your
| ability to predict how something will actually turn out under
| real world use and requirements.
|
| But I also find people insisting "the perfect is the enemy of
| the good" while trying to do crap. Why bother trying to do
| better than crap, the perfect is the enemy of the good!
|
| Determining what is "good enough", over the sustainable long
| haul, is literally the whole trick to software design. At what
| point you are getting diminishing returns or even counter-
| productive complexity from trying to polish it further. If it
| was easy we wouldn't be having these conversations. Slogans
| still don't make it easy.
| [deleted]
| bayindirh wrote:
| "Perfect is enemy of good" is just another name for "make it
| run first, make it run fast next". It doesn't apply cleanly to
| everything, but if you have a deadline coming up, an acceptable
| solution which is gonna be polished in the very next iteration
| is a good compromise, IMHO.
|
| However, project management loves to mark things as complete,
| so getting it polished to usual standards is the hardest part.
| bjornsing wrote:
| I really like this one:
|
| _Think different. Simple is harder than complex, which means you
| 'll need to use your creativity._
|
| The KISS people tend to think simplicity is the easy route. The
| acronym basically says so. But it's the other way around.
| rmnclmnt wrote:
| Totally agree. Usually to achieve a KISS state you need a few
| iterations and refactors to understand clearly the perimeter,
| objectives, constraints, etc. It is dedication, constant
| feedback and utmost important: egoless engineering. Usually it
| pays off when you refactor something by removing hundreds or
| thousands of LoC and your whole test suite is still all green
| jrochkind1 wrote:
| I always think of the quote (maybe from Mark Twain? Maybe
| aprocryphal) "I didn't have time to write you a short letter,
| so I wrote you a long one."
| couchand wrote:
| It seems to be Pascal, originally.
|
| > Je n'ai fait celle-ci plus longue que parce que je n'ai pas
| eu le loisir de la faire plus courte.
|
| https://quoteinvestigator.com/2012/04/28/shorter-letter/
| gyulai wrote:
| Pareto's law really isn't a law.
|
| You think that the world is full of situations where 80% of the
| payoff comes from 20% of the work/complexity/whatever?
|
| I tell you that, equally, the world is full of situations where
| you get 0% of the payoff unless you've done 100% of the work.
|
| That latter observation is just as true as the former, but it
| won't make anyone into a best-selling business book author or
| motivational speaker, as it doesn't help with cognitive
| dissonance reduction when reflecting upon laziness and
| ineptitude, as Pareto's law does.
| orangepurple wrote:
| Pareto is generally framed as a principle not a law
|
| Difference between principle and law:
| https://philosophy.stackexchange.com/a/94475
| samatman wrote:
| The Pareto principle is a principle, not a law, agreed:
|
| https://en.wikipedia.org/wiki/Pareto_principle
|
| The conflation being at the root of most of what you said is
| unfortunate: Pareto's law would indeed be a bad law, if it
| existed.
|
| Yes, I think the world is full of situations where 80% of the
| payoff comes from 20% of the work.
|
| I'd even be cheeky and say that the Pareto principle applies to
| about 80% of situations.
| xcambar wrote:
| So for 20% of the situations, you have to do more than 20% of
| the work to get 80% or less of the payoff?
| musingsole wrote:
| But I only _enjoy_ 20% of the work...so there must be a way to
| make that the only part I have to do and still get a promotion!
| jrochkind1 wrote:
| Oh, optimizing for promotions (or $$ generally) and
| optimizing for doing a good job are frequently not the same
| optimization. Beginning with your choice of where to work and
| going on from there.
| Cthulhu_ wrote:
| This is a Problem with a lot of software developers, leading
| to interesting developments like microservices.
| dkarl wrote:
| > I tell you that, equally, the world is full of situations
| where you get 0% of the payoff unless you've done 100% of the
| work.
|
| It depends on your perspective. For a lot of those 100%
| situations, you could think up some high-effort, low-payoff
| bells and whistles to turn it into a 80%/20% situation.
| Yujf wrote:
| Also you can make software that does what you need it to do,
| but feels bad to use because it is not polished because that
| 20% was not deemed important.
| dahart wrote:
| The Pareto Principle is just a kind of byproduct of variation
| in distributions, it may fall naturally out of a normal
| distribution and/or a Pareto distribution
| (https://en.wikipedia.org/wiki/Pareto_distribution) and/or
| Zipf's law (https://en.wikipedia.org/wiki/Zipf%27s_law), which
| are all in fact very common in reality, and why the Pareto
| thing is frequently approximately correct has been observed by
| many.
|
| Distributions of behavior that are perfectly flat like you
| suggest might exist, but are less common in large populations
| or samples. Do we have any names/principles/laws relating to
| flat distributions in nature or human behavior? I'm curious if
| you could give some examples of what you're thinking of, the
| situations where there's 0 payoff until all the work is done,
| and what basis there is for claiming this is equally true and
| common as varied distributions?
| nuancebydefault wrote:
| Thing is, the Pareto principle is not so very useful for a SW
| engineer. It's merely a mathematical fact. If we focus on the
| 80 percent that only takes an easy peasy 20 percent of
| effort, there's no product to deliver. The devil is in the
| details, details we need.
| aGHz wrote:
| The minimum viable product concept comes to mind. You don't
| have a product until you invest the effort required to pass
| the minimum threshold.
|
| Another example I can think of is escape velocity. I'd
| venture that the principle you're asking for is "phase
| change", where a threshold gates a drastic change in
| behavior.
| dahart wrote:
| Isn't MVP the canonical example of attempting to get some
| payout while specifically not doing all the work? It is by
| definition unfinished, and so not doing all the work yet.
| And the idea is to hit the threshold yeah, but what makes a
| product minimally viable is notoriously murky and difficult
| to pin down. "Viable" is pretty much always a subjective
| metric, it depends on your financial situation and runway.
| From experience with my own startup, there absolutely was a
| distribution of behaviors for different MVP effort levels,
| and the product was never 100% done, but we had paying
| customers, and doing more of the right kind of work
| increased the number of paying customers.
|
| Phase change in physics certainly is an example of a narrow
| peaky distribution, I'm just not sure how often that kind
| of distribution is a reality for human behavior, which is
| what the top comment was reacting and referring to. I can
| think of a few and was just arguing they exist in another
| thread elsewhere when it comes to pricing and consumption
| for scarce-resource high-demand economics. So they're out
| there, but I'd be pretty hard-pressed to agree that these
| are common enough to make claims that they're equal to
| distributions with lots of variation. It feels like the top
| comment was making an assumption, arguing that the Pareto
| principle is a made-up idea that's just as common as other
| made-up ideas, but that's not really true.
| rogersnm wrote:
| > I'm curious if you could give some examples of what you're
| thinking of, the situations where there's 0 payoff until all
| the work is done
|
| Not op, but surgery strikes me as an example where there's
| effectively 0 pay-off until you finish everything. I
| personally wouldn't want the surgeon to sack it off without
| sewing me back up.
| dahart wrote:
| It surely depends on exactly what surgery we're talking
| about, but surgery has lots and lots of known variation.
| Open brain and heart surgery might be good examples of what
| you're talking about, but surgery in general is one of the
| best examples of non-flat distributions with non-binary
| outcomes. Some surgeries can be abandoned in the middle
| without stitching the patient, and some people will survive
| even if most die. Heard a fun podcast just yesterday about
| fistulated stomachs and the stories of a couple of
| different people who've had them. Surgeons can do a
| mediocre job stitching and fail to clean everything and
| there will be a mix of outcomes. They can do a perfect job,
| and most people will live, but still a few will die anyway.
| tresil wrote:
| > ...the world is full of situations where you get 0% of the
| payoff unless you've done 100% of the work.
|
| Well stated. Deep down I've known this to be true, but since
| Pareto's law is often over used, it's easy to lose sight of
| other aspects of reality. This one is often overlooked.
|
| Judgement must be used to understand how these two concepts can
| apply to a given situation or decision.
| softwarebeware wrote:
| > Pareto's law really isn't a law.
|
| No "law" of software or business is technically a law in the
| same rigorous sense that a scientific law is. But that's not
| why we call them laws and it would be nitpicking to call that
| out, besides entirely missing the point.
|
| Also, it's actually the Pareto Principle
| (https://en.wikipedia.org/wiki/Pareto_principle) not "Pareto's
| Law" but that's also nitpicking.
| mkl95 wrote:
| A better made up law is that, given a complex enough product,
| simplicity is inversely proportional to the underlying
| complexity. An Airbus A380 is a long shaft with windows and
| wings, etc. This only applies to non brutalist design though.
| gw98 wrote:
| I think it's more that 80% of the work is unnecessary. There is
| so much waste in software engineering it's embarrassing.
| temporallobe wrote:
| Every time I do `npm install` I am reminded of this. Why do I
| need 32,127 libraries again?
| gw98 wrote:
| I have solved this by refusing to use anything involving
| node or npm. We had one project kick off with that and it
| was a lesson in supply chain attacks within a week.
| mihaic wrote:
| Most of these are the sort of "common sense" things you'd get
| with experience, and I mostly agree with the ideas behind this.
|
| Where we fail as a craft though seems to be in passing on this
| information to those not yet convinced.
|
| Inter-generational transfer of robust best practices might be
| fundamentally intractable since often worse practices (pushing
| featurea over solving technical debt, adding needless complexity
| and bad abstractions) actually pay well. At the same time, it's
| not like we're putting in too much effort into this.
| pydry wrote:
| I think that's largely the fault of the medium/way the message
| is crafted. This looks like it aped the agile manifesto which
| almost went out of its way to be unactionable and vague.
|
| In both cases I'd say that the authors is _getting_ at the
| right idea but they haven 't really formulated it precisely in
| their heads.
|
| As such the value is clear to the experienced person with the
| benefit of many years hindsight but not to the newbie.
| mihaic wrote:
| Agree, but I still don't know if there is a way to format the
| message in a way that the average newbie can actually accept.
| pydry wrote:
| I usually formulate the hard learned lessons in the form of
| stories.
|
| XP kind of did this with the whole Chrysler thing.
|
| I reckon a website that aggregated these stories would be a
| more powerful illustration.
| rob74 wrote:
| Looks like they applied their recommendations for software
| development to their manifesto as well. The grammar is definitely
| not perfect (maybe not even good).
| [deleted]
| return_to_monke wrote:
| Well, the authors could have invented their own network stack.
| Since they didn't, it's minimal.
| Thoreandan wrote:
| (1994)
|
| * Futurist Programming Notes -
| http://www.graficaobscura.com/future/futnotes.html
|
| * Manifesto - http://www.graficaobscura.com/future/futman.html
|
| * Background - http://www.graficaobscura.com/future/
|
| My favorite exercise:
| http://www.graficaobscura.com/future/futnotes.html#:~:text=R...!
| redleggedfrog wrote:
| I would add "Don't write code unless you have to."
| bvirb wrote:
| I think what made this work for us at work is that we (maybe
| accidentally) made refactoring very cheap and easy. We write
| almost entirely integration tests that only interact w/ the UI,
| so not much about the tests is tied to our architecture (instead
| they're coupled to the UI). The tests run slower than typical
| highly optimized unit tests of course, but the trade-off is that
| we can refactor things without breaking the validation that
| everything still works. This then makes continuous improvement a
| lot easier to realize than I have experienced in the past, since
| changing our minds is relatively painless.
| oa335 wrote:
| This is why I like writing end-to-end tests first (and often
| times the only thing I write). Unit tests come later after I
| have decided on solid, reusable lower level abstractions.
| Unittesting to early makes refactoring too hard.
| bullen wrote:
| I disagree with Perfection and Premature Optimization quotes:
|
| With the fossilization of hardware we can, and inevitably will,
| write the last software at some point.
|
| There will be one best web-server, game-engine etc. for every
| domain.
|
| It's just a question of time, and then that IS what those
| implementations will be: Perfect and Optimized to no end!
|
| Together with simplification and other guidelines these projects
| will probably be <10.000 lines.
|
| You need to be able to learn from them.
|
| A project like Unity or Unreal might be open-source/source
| available but if it's so bloated nobody can understand it there
| is no value long term.
| jrochkind1 wrote:
| > we can, and inevitably will, write the last software at some
| point.
|
| Maybe, but the context/requirements change too. For one of your
| examples, what a web server is desired to do changes with
| HTTP/2, and that may mean the "last" web server no longer is.
| But even less drastic/specific things can change desires and
| requirements; things change, even if hardware doesn't.
| bullen wrote:
| Well, if you believe HTTP/2.0 is an improvement then good
| luck to you.
|
| For me it's HTTP/1.1 until humans run out of electricity.
| jrochkind1 wrote:
| That was just one example, but the fact that people
| disagree on it seems enough to be an example of why the a
| "last webserver ever" would stop being so. But it was just
| one example. There are things other than hardware changes
| that make people want something different out of software.
| Maybe not you, maybe you never change what you want out of
| software for any reason. if so you are extremely atypical.
| -\\_(tsu)_/-
| bullen wrote:
| I don't chase eternal growth, I stop when I see something
| that is good enough:
|
| So OpenGL (ES) 3, HTTP/1.1, JSON, SMTP, DNS...
|
| But one thing that I have learned is hardware progression
| (C64 -> Amiga -> PC -> Raspberry 4) and that race is
| permanently over for humans for eternity.
|
| So we'll see what happens to software!
|
| Finally you can't just throw more energy at a problem,
| you actually need to write code with limitations in mind
| again!
| pramodbiligiri wrote:
| I think this is highly under appreciated. A particular piece
| of software exists in a technical, social and economic
| context. If any of these change, it opens up the space for a
| replacement or a new addition.
|
| Some big changes are desktop to web, web to mobile, single
| user to multi-user, power user to newbie... and so on.
| mark_l_watson wrote:
| I was working in a new book project on Saturday using old and
| highly optimized tools: LaTeX/TeX and Emacs. I am deeply
| appreciative of people who maintain and improve these tools,
| they are not Dead projects by any means.
|
| I am against a world economy based on mandatory high growth. I
| am also against new tech, just because something is new. I make
| exceptions: deep learning applied to real world problems,
| better theories and implementation for security and privacy,
| and better online platforms for creating things; for example
| leanpub for writing and Google Colab for writing and sharing
| ideas and experiments in ML and DL.
|
| How often are we disappointed when new versions of software
| seem worse than previous versions?
| gizmo wrote:
| Minimalism is often a fantasy. If you want to make a great
| product for the end user you often have to much more engineering
| work in the backend to give the illusion of simplicity. You can
| click on any link to open a website, but there is a tremendous
| amount of complexity behind the scenes (DNS, TCP/IP, HTTP, SSL,
| routing) to make it all work. The abstraction is simple for the
| user, but complicated in reality. All of these individual
| technologies can (and perhaps should be) simpler and more
| minimalistic, but the totality of the stack is inherently
| complicated because it solves a hard complicated problem.
|
| Suppose you want to make a new graphics app. Do you want users to
| easily create beautifully typeset documents? Then you'll have to
| do a ton of schleppy hard work to give the user the option to
| bend/morph/scale graphics to their taste. A "minimalist" graphics
| program isn't any good because then the designer won't be able to
| create what they have in their mind.
|
| Code isn't written for other people. Code is written so the end
| user ends up with a great product that solves their problems. If
| you're lucky the code is minimalistic and beautiful, but usually
| you'll have to struggle through one schleppy problem after
| another to give users the features and performance they desire.
| robinsonb5 wrote:
| Minimalism isn't always about eliminating or avoiding
| complexity - though sometimes it is; sometimes it's about
| having the discipline to avoid wastefulness.
|
| External constraints can be the driving force here - I have a
| project which involves firmware running on a soft CPU in an
| FPGA. I'm targetting several different devices, but the project
| will no longer fit the smallest device if my firmware (code,
| working RAM and stack combined) goes over 12 kilobytes. In the
| middle of working on this project I took delivery of a new
| workgroup printer at work, the remote monitoring software for
| which was a 1.5 gigabyte download. And apparently we live in a
| world that sees nothing wrong with that!
| dale_glass wrote:
| Other options were tried and rejected, or aren't viable. Eg,
| you have this 1.5GB of stuff, what's there? Probably:
|
| 1. Graphics and videos. Nice, high res, smooth animations
| showing how to operate the printer.
|
| 2. Frameworks. Because Qt libraries don't come with Windows.
|
| 3. Various dependencies
|
| In turn, each of those explodes due to human needs and
| convenience. Eg, you have an animation that says "Press here"
| in text. You sell the printer internationally. You'll
| probably have 20 different versions of it in every supported
| language.
|
| A large amount of complexity works down to human convenience
| -- Unicode requires large fonts and complex software
|
| Some is because the platform is what it is. Windows doesn't
| have a package manager, so it can't pull in libqt5 for you
| when you try to install an app -- so it has to come with the
| app.
|
| We've also agreed that every app shall bundle its own
| dependencies, because DLL hell was really hell, and trying to
| have one system-wide copy wasn't working.
| ferbivore wrote:
| On the contrary, it seems like you'd have to try very hard
| to ship 1.5 GiB of software.
|
| For example, Calibre is around 350 MiB. It embeds Qt,
| Chromium, Python and ICU, is fully localised, and has
| rather a lot of functionality.
|
| Video content can be fairly large, but a high-quality 1080p
| encode is around 500 KiB/s. Can you really pack an hour of
| instructional videos into some printer software?
|
| I can think of a couple ways that you could cross the 1 GiB
| mark, but none that would involve sane engineering choices
| or "trying and rejecting" other options.
| robinsonb5 wrote:
| To be fair, bundling a Java Runtime Environment will give
| you a decent head start...
|
| Having to ship instructional assets in multiple (human)
| languages is a fair point, and one I hadn't considered -
| though in this particular case there are no movies or
| animations that I've seen.
|
| Most of Dale's points are correct, though - but that
| doesn't make it a sane state of affairs, and it saddens
| me that we just accept it with a sense of dejected
| resignation instead of trying to do better. I had
| (obviously naively!) expected the the microchip shortage
| to prompt a massive drive to extract every bit of value
| from the ones already in service.
| fdsafdewe wrote:
| >Minimalism is often a fantasy.
|
| In the software world, yes. The question we should be asking is
| "Does this product need a touchscreen / app / web interface?"
| There is no "minimal" way to invoke the efforts of half of the
| world's FOSS (and other) software developers so that you can
| have a "beautifully" animated button to dispense coffee (yes,
| my workplace has a coffee maker with touchscreen, and I hate
| it).
|
| As a software engineer who personally wrestles with this
| conundrum on a daily basis, I'd love to set up a "you don't
| need software" design agency.
| [deleted]
| heuermh wrote:
| > I'd love to set up a "you don't need software" design
| agency.
|
| Sign me up!
|
| If it helps, I have an large collection of antique and
| vintage knobs, switches, pots, buttons, and sliders. ;)
| bjornsing wrote:
| > Minimalism is often a fantasy.
|
| True to some extent I guess. But in my experience "hipster
| perfectionism" is also a fantasy.
|
| It's easy to think that if we make the user experience
| _exactly_ the users (or in most cases actually some product
| manager) wants it then we'll have massive traction. In reality
| that's rarely what happens. In many cases I would say nothing
| at all happens.
|
| As an example I ran the analytics group at a moderately
| successful startup a few years back. The engineering team put
| in massive effort in a new release that would be so much more
| polished and easier to use. But when we looked at the numbers a
| few months later it was impossible to discern any meaningful
| change around the deploy date. I didn't say anything about this
| to the higher ups of course, and neither did anybody else.
| gizmo wrote:
| Absolutely. No way to tell in advance if a big new release is
| going to work, and it's all too easy to make a product better
| in 10 unique ways that just don't matter. You can't A/B test
| yourself out a local maximum, and some point you have to go
| for a big new release despite the risk.
| [deleted]
| valenterry wrote:
| > Code isn't written for other people. Code is written so the
| end user ends up with a great product that solves their
| problems.
|
| Of course it is written for other people, at least if your
| future self counts as another person. Or is it write-once-
| never-look-at-it-again code? Then yes, but that's rare.
| Existenceblinks wrote:
| Javascript ecosystem from 2013 to today is almost 10 years now,
| it's a crazy ride. Imagine folks create the whole market out of
| backbone.js, so much minimalism.
| [deleted]
| yandrypozo wrote:
| I like the idea and it would be better if they included the old
| Unix philosophy https://en.wikipedia.org//wiki/Unix_philosophy
| TheUndead96 wrote:
| I find the idea of a manifesto in software quite off-putting,
| since it is inherently idealogical. The ideology itself might
| have redeeming factors, but I think that it is a poor vehicle for
| conveying ideas. This manifesto is written in the first-person
| ("There's something I call fixing a bug by sedimentation"), but
| it is trying to be universal. If this person has opinions on
| software engineering, why not just voice those as an individual?
| [deleted]
| [deleted]
| TickleSteve wrote:
| Agree with the thought behind these, but the wording is
| terrible...
|
| "synthesis"? In what context is this word being used? "clean
| kipple"? I've never even heard of that word.The first google
| result for "kipple" is some reference to Blade-Runner!?
| [deleted]
___________________________________________________________________
(page generated 2022-11-07 23:01 UTC)