Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Professional Corner-Cutting (2016)

blog.ometer.com

Post reply on HN
Print view View original

41–50 of 142 posts

Re: Professional Corner-Cutting (2016)

#41

Post by bojan »

ungreased0675 wrote: post #4

I like the last paragraph. Will remember that when an engineer slows down a project talking about code smells and revisiting architecture decisions. > Professional software developers are performing a service for others. That’s the difference between a professional and a hobbyist or an artist.

There is certainly a a balance to be struck. Are the code smells a structural issue in a piece of software that's supposed to be used and modified for a long time? Then those code smells endanger delivering the service in a medium term and should be addressed.

But are we talking about a one-time migration script or a fad mobile app? Then who cares, the service will be delivered regardless of the quality of the code.

Re: Professional Corner-Cutting (2016)

#42

Post by rapfaria »

RangerScience wrote: post #36
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

You know I wonder… why do so many of us feel like we need our boss to understand?

Perhaps it's not a close relationship. Perhaps the boss is insecure about his management skills and has to constantly check on the team, to make sure every variable is under his radar.

Re: Professional Corner-Cutting (2016)

#43

Post by skydhash »

ilaksh wrote: post #18

Oftentimes managers will make demands that interfere with ownership of the code. Such as requiring something to be finished in half the time it would take to do it without technical debt. Over and over and over again. I have had a lot of clients like this. It's very common especially for lower budget projects. You can literally cut corners you don't really want to or just get replaced by someone who does. They will o…

More often than not, you have n > 1 implementation solutions possibles. The article said to factor the constraints into the choice of solutions, not the solution itself.

Like if it would take 6 months to implement a backend, but just 1 month with Firebase, and time is a more important than data ownership, you go with Firebase. Then you prepare a plan if you ever need to migrate off Firebase. If you don't have time to do a custom UI, you go with a components library. That also means knowing the range of possible solutions (aka mastery). If nothing else, you reduce scope.

There's a plethora of ways to respect time/monetary constraints without resorting to shoddy code and duck taping.

Re: Professional Corner-Cutting (2016)

#44

Post by jack_h »

I'm going to have to disagree with the entire premise of this piece.

If you are a cabinet maker you have many individual clients who all want what you're producing. They each have their own budget and preferences that you can work with to get them something they want to buy. The incentives and constraints are clear here. If you can make something the client wants at a price and quality point they can afford you will do well.

Many (most?) software developers create a product to satisfy the needs of many customers and non-customers simultaneously. Furthermore you almost never interact directly with customers; instead developers interact with a panoply of different business interests such as engineering managers, product managers, project manager, product owners, etc. Even worse software doesn't have to be done to ship it as it can always be fixed "later". With the advent of Agile, Scrum, and SAFe it's clear what the business wants is not someone good at a craft; they want an assembly line.

So what are the incentive structures and constraints here? Every other person has incentives for career advancement, bonuses, raises, etc. Most people are too far removed from customers to be directly affected by them. How many times has a cabinet maker been told that the hope chest they're working on for one client also needs to double as a bank vault. Oh and by the way it needs to be done by the end of the quarter (right after layoffs of course) because they are hoping to be bought out. Code bases end up being a fractured mess of bad abstractions, infinite abstractions, and rewrites because developers are trying to accommodate the impossible demands set forth by the business in a way that doesn't cause their job to be abject misery.

TLDR: most software developers are not expected to be craftsmen (or women). The company determines, through incentives and constraints, the quality of code it will produce. An individual software developer risks burnout if they think quality above and beyond what the company allows is within their responsibilities or capabilities.

Re: Professional Corner-Cutting (2016)

#45

Post by yakkomajuri »

In a lot of organizations I feel like #2 is often the difficulty. However, interestingly there is an opposite phenomenon where people are too focused on #2 (understanding customer needs) and thus fail at #1 (owning implementation).

I've seen it happen where non-technical users of internal tools request very specific features that get built just because and at whatever cost without the team asking what is the actual problem this feature solves and how can we best build something to address the problem given our knowledge of the technical side. It's often requests for tools that allow people to do things manually when the team should just spend some time automating away the need to manual intervention.

Re: Professional Corner-Cutting (2016)

#46

Post by tejtm »

ricardobeat wrote: post #28
tejtm wrote: post #27

Earlier quoted context omitted.

That was done in Amiga 1000 cases 1985-ish. I would be surpised if they were the first. https://www.commodore-info.com/computer/item/a1000/en/deskto...

The parent folklore.org link mentions this happened at Apple in 1982, end of first paragraph.

And, Jobs visited Amiga in 1983 which also suggests the idea came from him.

Re: Professional Corner-Cutting (2016)

#47

Post by Vinnl »

One of my frustrations is how people often seem to drift towards one of the extremes on either side of this argument. Technically, the approach described in this article is called 'pragmatism', but in practice, people have used that term to describe the bad kind of corner cutting.

And whenever you're arguing against someone drifting too far to one of the extremes, you'll often get lumped in with those on the other: to a perfectionist, you'll be considered a lazy, sloppy worker, whereas the corner-cutter will consider you to be super pedantic and not the type to 'get things done'.

On the other hand, when you do get to have a proper discussion on whether a corner is worth cutting — i.e. if it will actually affect the user's experience — and you end up being able to save time without materially affecting the end product or future maintenance work, that is enormously enjoyable.

Re: Professional Corner-Cutting (2016)

#49

Post by baobabKoodaa »

bojan wrote: post #41
ungreased0675 wrote: post #4

I like the last paragraph. Will remember that when an engineer slows down a project talking about code smells and revisiting architecture decisions. > Professional software developers are performing a service for others. That’s the difference between a professional and a hobbyist or an artist.

There is certainly a a balance to be struck. Are the code smells a structural issue in a piece of software that's supposed to be used and modified for a long time? Then those code smells endanger delivering the service in a medium term and should be addressed. But are we talking about a one-time migration script or a fad mobile app? Then who cares, the service will be delivered regardless of the quality of the code.

There are people working in software who will _always_ want to refactor something into "clean code", no matter how many times it has been done before. It's just never going to reach a point where that person says "I'm happy with it, let's get back to building features". If you want to build features (at all!) then you have to sometimes tell that person "no, we're not refactoring this again".

Re: Professional Corner-Cutting (2016)

#50

Post by onion2k »

RangerScience wrote: post #36
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

You know I wonder… why do so many of us feel like we need our boss to understand?

Most of us work in organizations where the boss is a former engineer who understands the problem of tech debt perfectly well. If your boss is a former dev and they aren't taking it seriously the problem is usually that they're a bit too keen to say yes to other parts of the business.
Post reply on HN