Hacker News Reader

Comment by blowski | Hacker News Reader

Technical debt in CSS seems to be both more inevitable and less problematic than application code. By the time it becomes a problem, either marketing decides on a redesign or the latest frontend lead wants to use a new framework.

So “screw it, this works” seems to be an entirely justifiable methodology.

View on HN

In my career, I've gone from Waterfall, to XP, to Agile/Scrum methodologies.I've also spent some time doing V-Model. Personally, I'm looking forward to the switch to the "Screw It, This Works"™ methodology. Looking forward to the Addison-Wesley book series!

Edit: I've just founded the "Screw It, This Works"™ Alliance. Sign up today to become a certified SITW Master.

we call that “fuck it, ship it”

or exceptionally better "Fuck it, we'll do it live"

“Let’s get this working in prod; after that, we’ll back patch it to dev…”

"Git push is prod push"

Brand it FISIcal Project Management.

Deadline Oriented Programming.

I've seen the "it mostly works, ship it and we'll fix it later" approach used. The second part usually doesn't happen of course

Well, do you want a promotion or not?

Followed by "The Production environment is just Big Test"

I work in a rather small company, but we are 100% WFH and we span quite a few timezones (From South America to South East Asia). Just yesterday I was summoned at 22:00 to un-fix a small previous fix that had been introduced earlier in the day and was affecting the production site... And the fix was meant "only" for test domains.

I like the saying that software isn't released, it's allowed to escape.

> fuck it, ship it

This is a sub-domain of Fuck Users, Ship Excrement, or FUSE-Dev.

It's way better than "Screw it, it probably doesn't work, but we have new projects to work on."

Or my personal favourite: "Screw it, this works, but I'm bored so I'm going to add 3rd party libraries to it until it doesn't work".

> "Screw It, This Works"™ Alliance.

Where is the conference and the website to download a frameable printable "Certified SITW Master" certificate?

The way you earn the certificate is by making it yourself in MS Paint, from one of your other certs and a screenshot of the logo you take from the website.

I'm a fan of the TFTGAF (too fried to give a fuck) Coding Methodology... Everything else is an anxiety disorder.

If you use "Helps" instead of "Works" (Screw It, This Helps)

Then you can have the SITH Alliance and give out SITH master certifications.

And in 10 years, there would be daily team screwing sessions...

When do we get to write a manifesto?

you are looking at it

It's all fun and games until you drop a decimal and end up in some real trouble fast.

> So “screw it, this works” seems to be an entirely justifiable methodology.

I've become more aware over the years that some developers, especially very senior ones, are under the fatally mistaken assumption that the problems start when the complaining starts, when it's closer to the truth to say that the real problems start when the complaining ends.

There can be bad developers on any team of course, but there are many developers who know or suspect what they are considering doing is wrong, and discover that asking someone about it is far more trouble than its worth. They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.

Every project has problems. Even the ones that are making millionaires out of relatively new team members. If you aren't hearing about those problems, that's entirely, 100% your fault.

Not all problems have to be solved before they become an issue though.

Its often a pointless effort, especially if the problem boils down to "this architecture isn't pure enough"

The point of the post isn't that all problems should be given equal credence, but that all problems should be at least acknowledged. Im the end would you rather a Jr. dev who's been working on the project for 6 months be the one who decided whether the problem is important enough to be solved or the Sr/project lead?

You know you can acknowledge a problem and that doesn't mean you have to solve it this very instant, right? It's not a matter of either dropping everything or gaslighting people^W^W dismissing the issue as trivial. There are other choices. Many other choices.

If you don't think the problems people are bringing you have merit, then they won't bring you any problems at all, even when they have merit. Suck it up and realize that you're going to have to allocate a little bit of time on "good problems to have" (if this is our biggest problem right now, things are going very well) or you'll either introduce latency into your early warning system or shut it down entirely.

> if the problem boils down to "this architecture isn't pure enough"

Then the problem is that your coworkers think that purity is a magic shield that will protect them from all ills, which is a bigger problem. You still need to hear it, even if you don't like it.

Honestly though a lot of times when I find myself at odds with someone they try to dismiss my concerns as matters of purity when what I'm really complaining about is the smoke that's coming out of the machine (or the team's ears) because they're riding it too hard. Sharpening the saw isn't aesthetics. Preventing wear and tear isn't some white tower bullshit. It's about keeping something in the tank for the next problem we don't know we have yet. People who don't believe in burnout are doomed to create it, usually in others.

People think they’re designing a spaceship, when in reality they’re building something closer to IKEA furniture.

YAGNI applies to a lot more than most people think it does.

Targets of opportunity are problems that have a distinct value in being solved which is less than the naive cost of fixing it.

Not the actual cost of fixing it, the 'drop everything and work on it now' cost, adjusted for Murphy's law. These are often the sort of 'nice to haves' that come out to 3 months of work, which nobody is going to approve unless a customer is actively yelling in their face about it. And sometimes not even then.

Refactoring is Make the Change Easy, Then Make the Easy Change. If you don't know what your targets of opportunity are, because you have some misguided notion that you can't [have an adult conversation about the state of things](https://www.jimcollins.com/concepts/confront-the-brutal-fact...) without tender egos being hurt, then instead of moving toward any of the horizons you'll just sail in a big circle while people keep trying to get you to venture farther afield.

The problem I often see is in the evaluation of the naive cost of fixing it versus the actual probability your target of opportunity will become a legitimate design consideration. The naive cost almost always is large but the probability your target of opportunity will be necessary is often small or miniscule. It's easy to try to cover all your bases and write something in an unnecessarily flexible way when a concrete implementation would have solved the immediate requirements succinctly and very likely may not to be touched again for years (if ever again).

> real problems start when the complaining ends

I really like this quote, and I'm gonna reuse it in a slightly rewritten fashion. In SE teams, indeed, the amount of complacency is directly related to the amount of increasing technical debt.

Often the complaining ends because the complainer leaves. And now you have two problems.

> when it's closer to the truth to say that the real problems start when the complaining ends

Oh, no, when the complaining ends, the problems didn't just start, they reached the magnitude where they are unsolvable long enough ago that no one even harbors any glimmer of hope of fixing or even meaningfully mitigating them.

... yeah... that's a whole row of ice cream flavors of its own. There's depressed despair, betrayed despair (chocolate and vanilla), cold disdain (mint) and red-hots (if I think about this I will get so angry that I will do something career limiting, so I cannot think about it anymore).

I'm still trying to work out how I communicate to someone that the things I have stopped mentioning might still be bothering me, and so fixing the two things I'm actually harping on won't magically make me happy. Maybe that's just something people are supposed to work out for themselves. Mostly I seem to have figured out how to do this when three or more people are involved (basically hand all of my fodder to someone who is still engaged, and let them run with it), but not when it's one on one. Conversations with people who can't 'look at things' can be exhausting, and that seems to hold no matter which party you are.

> They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.

There is a gradient I've seen with IT workers in general, that is doing IT as a passion and doing IT for a job. Disciplining someone for not knowing enough though is a bit much.

> real problems start when the complaining ends

By this point no one cares anymore and the technical debt is beyond fixing.

I dunno. I know of a project that lingered in this spot for a couple of years before enough people who cared had left to make it a truly lost cause. But there was no leadership to speak of to motivate any of those people, and most of them left. There were points right up until the end where these people were sprinkled across enough of the organization to be a beach head for doing something, but then they lost people on two teams in as many months and from then on it is destined to be status quo. Or at least until they decide to binge on a tech stack update, hire too many people but not for long enough and end up back where they are now. From what I understand they've done that a couple times already.

> Technical debt in CSS seems to be both more inevitable and less problematic than application code

Nicely put. I've stressed over finding unused rules, restructuring, etc. but in the end it never matters as long as it displays correctly.

The big problem is knowing all the places which could be displaying incorrectly when you make a change. This is a fundamental design issue with the cascade: unbounded silent failure because rule activation is implicit.

In addition, there is the difficulty of inspecting those sites which you can identify to verify that display is correct, which is hard to achieve programmatically.

It's not inevitable. I love Svelte partly because it solves the problem by compartmentalizing CSS to the UI component I'm working on. It feels natural that if I write CSS in a file for a component it shouldn't be seen by other components in general.

Even without Svelte, most of the problems people have with CSS go away if you do the following:

- Avoid cascading (i.e. no nested selectors except when there's "no other way")

- Implement separate selectors for styling and page/component layout (separation of concerns)

- Using a good naming convention and stick with it

The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading.

I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.

I believe that Svelte is so natural extension to the current web that - just like with CoffeeScript and ES6 - some of it should be adopted.

Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.

this is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Thanks, it looks great. I'm happy that they didn't rush it. They don't talk much about compatibility with current web frameworks, I think they should. I really hope that it will be featureful enough to support being a target for compiling Svelte components (or even maybe React / Vue components) to HTML modules to be imported at some point, but still stay simple enough to be useful.

Points 1 and 2 sound a bit like CSS's new "layer" feature

Mind telling a bit more on this second part "Implement separate selectors for styling and page/component layout (separation of concerns)"? Are you referring to classes (for styles) and probably id's for Javascript?

Layout is the structure of the page, grids, master breakpoints etc. eg. .grid .row .column .banner

Styling is setting colors/fonts/padding etc on a specific component.

eg. .sign-up-form .delete-button .accept-button

> I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.

Yep. I find of the usage of !important I see daily is failure of the programmer to understand precedence rules, which, as you pointed towards, is mostly due to cascading.

On the other hand, I find Svelte's handling of this half-baked, as there's no way to pass scoped classes to a component, only to a HTML element. [1] In fact, I find this so frustrating that I have actually given up on Svelte's CSS scoping entirely and I use Tailwind instead, which also solves the same problem by almost [2] completely disregarding the cascade altogether.

[1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?

[2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.

One of the questions for passing scoped classes to a component is why you want to do it. If you have complex selectors, it would effect the implementation of the component, so I think that would be an anti-pattern. Just modifying the root would be great, but in Svelte I believe one component can translate to multiple root nodes, so all of them would need to get the styles, which again would increase the coupling between the component usage and implementation. I think there's just no clean way to do what you want.

I already said why in my first comment:

> Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?

Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either.

As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.

> It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it.

Again, the child component can't decide what to do with a class, as it can't know specifics about the parent. It would break the modularity.

I checked the most commented issue, it's about the reactivity system doing only one round of checking in topological ordering, which could be fixed, but could cause infinite loop, and again the problem is not implementation, but deciding on the best design:

https://github.com/sveltejs/svelte/issues?q=is%3Aissue+is%3A...

Over a lengthy career writing code, I feel like I've gotten pretty good at writing clean, maintainable, legible, changeable code. Especially in the languages I have the most experience in.

I don't feel like I have any idea how to write maintainable legible changeable CSS. Like, it's not just that I can't afford the time -- I just don't know how to do it, despite all my efforts the CSS becomes monstrous, always.

This is why, as someone who loves writing CSS and thinks they're reasonably good at it, I've come to the conclusion that writing CSS is an anti pattern, and if you want teams to quickly build interfaces with a maintainable "frontend styling layer", it should prevent the ability to write css.

What would you recommend instead of CSS?

Tailwind

… which is a CSS utility class library and thus suffers from some of the same pitfalls.

How about something like Ant Design?

Unless something major has happened to it since I used it, Ant uses a giant ball of SCSS with complex selectors that make it ridiculously hard to customize without hacking the source.

Hacking is exactly what we are trying to avoid. Just change the variables to suit your branding and compile the SCSS yourself, just like Bootstrap (which was using LESS but otherwise the same idea).

Never been an issue for me. I hear this a lot though, it's probably not for everyone.

> complex selectors that make it ridiculously hard to customize without hacking the source.

This, to me, is a feature. Don’t customise it.

tables

It must be CSS in the end, but you should create/use a component library, that has the right set of primitives (and less-primitives) that lets end feature developers create the UIs without having to resort to manually write CSS.

THis is made significantly easier when you have designers working with this "design library" mindset also.

I've come to the conclusion that writing CSS is an anti pattern

I don't think this is true. The biggest problem is people who write CSS do it as if they want CSS to be something else and are trying to force it to be that.

Writing CSS using ITCSS (Inverted Triangle CSS) [1] solves so many of the issues devs complain about it. It's simple: create layers in specificity order. Don't fight the cascade; make it work for you.

Writing good CSS isn't about getting the syntax right; it's about getting the architecture right [2].

Harry Robert's video does a great job of describing all the pain points ITCSS solves [3].

[1]: https://dev.to/carlillo/understanding-itcss-real-case-using-...

[2]: https://www.xfive.co/blog/itcss-scalable-maintainable-css-ar...

[3]: https://www.youtube.com/watch?v=1OKZOV-iLj4

I think the problem is that just not that many people know how to write good css and good JavaScript. So I try and just require them to only know JS.

I think it’s hard to hire lots (…hundreds) of developers who’s going to know CSS well enough to not screw it up.

I think utility-first frameworks like Tailwind are becoming popular because they allow frontend teams to say "screw it" without descending into total anarchy.

Eh, the successors of those current teams will still curse them and throw it all out when it comes time for a big revision.

Yeah, code written by the people before you is always bad

That’s fine for your brochureware whatever. Not fine for a line-of-business application meant to be useful for the next decade or more.

I used to work with 3 versions of a whole css system co-existed. To unfuck css debt is like to do surgery, make it done quick or you have vein spaghetti bleeding .. while is also running service.

OOCSS leads you to technical debt. The bigger you become, the easy you land into techdebt.

OO leads to technical debt in most cases. You can limit it to a narrow scope (interfaces), or you can have objects that wont move or inherit much (bascially if the parents can be replaced by traits), but someday someone will try to be clever and your team will soon enter OO hell. Bonus hell points if you allow third-party plugin in your software (shoutout to Jenkins!).

Reply on news.ycombinator.com