[ChrisMarshallNY]

Personally, I write software that I consider extremely high-quality. The folks that use it, seem to agree. It isn't eye-candy fancy, but it works very well, in a not-in-your-face manner.

The idea is that it does what it says on the tin, without fanfare, robustly, usably, accessibly, localizably, and dependably; providing a user experience that gets out of the way of the user, in a manner that does not surprise the user (even "good" surprises can be an issue. Boring software can be just what the doctor ordered).

In my book, that's the definition of "quality."

I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."

If this were a commercial app (it isn't), then it would have been unbearably expensive for a startup.

I tend to write test harnesses in a day or two, that have similar levels of functionality to this application.

High Quality is significantly more expensive than even "decent, but lesser" quality.

[tkiolp4]

You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high-quality and useful products), almost everyone hates software engineering.

[jagged-chisel]

I don't like this definition of Software Engineering that necessitates a team of Other People. Perhaps I'm outright wrong that such a definition just shouldn't be. Even in that case, I just don't like it. :)

[shalmanese]

If you broaden the definition of Other People to "you, 6 months from now" and "you, 6 months ago", then many SE principles still apply. Where SE principles don't apply is toy, one off scripts that you just hack together to get a single thing done and require no maintenance like a lot of stuff in science.

[ChrisMarshallNY]

I'm the poor schlub that usually needs to maintain the code that I write.

I also pretty much never get questions about the code that I pass on to others.

I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

(Long screed. Few read it).

[tharkun__]

Absolutely true. Not even 6 months needed.

When I do stuff for myself I apply the same principles I apply at work. It's insane how easy it is to change stuff later on. Didn't think about this use case before but now you do? Because I have properly maintainable code that is readable its very easy to change and changes are only needed in one place instead of all over the place. Knowledge of the right thing is kept in the right place instead of implicit knowledge all over the code etc.

It also helps to have 'one team be responsible for each service' instead of 'everyone can work on everything'. It's insane how fast you can move if you know the code well and it's maintainable.

[tkiolp4]

Strangely enough, software engineering is mostly about humans rather than about software. Take any side project of yours (no matter if it has been hacked together or if the best practices out there have been applied): add pressure to make money out of it, pressure to deliver it at a given date and a bunch of individuals you must collaborate with to push the project live, and right there you get SE.

[datalus]

I would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it.

So I would say engineer is a poor term, but also the only one we've got for now.

[ordu]

As I see it, it is more nuanced. When engineer designs a bridge she does a very similar work to a programmer. Programing it is like designing a very complex bridge without constructing it really, because when you finished your design it had been built already.

So it is not exactly like you've said:

> You can't design it first and then go and build it.

You can design, but you cannot build.

A process of building by a design can be paralleled with deploying software -- suddenly there is a hairy real world, not all the hair was considered at the design phase, and either we hack around existing software (i.e. design plans), or call a programmer to redesign.

[dnh44]

No it's not like building a bridge. It's like thinking you're building a bridge but then the client decides he needs it to be moveable so then you have to give it legs so it can walk. Then the client's manager decides he wants it to be able to get to the moon so you then have to strap rockets and parachutes to it. Then after it gets installed and someone finally speaks to the users you realise all they needed was a canoe.

[cloverich]

> You can't design it first and then go and build it.

You can't design it in full in one go, but you can design it and then incrementally update said design. Sadly many (companies) do not. But you can define the problem(s), the scope, the scale, and then design a solution appropriately to meet those needs (for a defined period of time). That's what distinguishes software engineering from hacking. They both have their place. Many companies claim to do the former but are mostly doing the latter. Software is still early in its life and as various kinds of system designs stabilize, so will the formalizations around what it means to be a software developer. Reading a book like Designing Data Intensive Application's you can't help but see those formalized topics budding.

[branko_d]

It's exactly like building a bridge... if nobody never built a bridge before.

The only reason you can design a bridge beforehand is because (millions?) bridges have been built before so you can apply the lessons learned. Even if your bridge is "unusual", it will still be similar enough to older bridges so you don't have to invent the vast majority from scratch.

Other kinds of engineering don't have the luxory of leaning on the prior experience so much, simply because there is less of it. SpaceX's reusable rocket could not have been be fully designed before built, simply because nobody built a reusable rocket before. But it could be done through iteration, which is just another name for experimentation.

Software tends to be less like bridges and more like rockets... all of which falls within the spectrum of "engineering".

[Rd6n6]

In Canada, engineer is a protected title. There are software engineers and you get professors who stress to you the importance of testing and safety, and there are safety and ethical requirements. It’s not very strongly enforced though, lots of people here get away with using the title

[cfcfcf]

Yes, I personally find developer or programmer more accurate, although neither is without its own connotations and baggage.

As a designer I’m a bit embarrassed by the trend to describe ourselves as product designers. To me a product designer makes chairs and coffee tables.

[motioncuty]

I mean, I'm and audio engineer, a fire protection engineer by degree, and a software engineer. Your bridge building analogy doesnt hold up, there is always changes and refinements of guestimations.

[blacksmith_tb]

Hmm, 'developer' has a cheerful kind of vagueness about it - it comes close to describing the iterative process of starting to write something one way, then realizing your original approach wasn't quite right and rewriting it. At least, I don't think mechanical engineers do that too often...

[ChrisMarshallNY]

Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping, as I do writing.

I consider everything I do, "engineering." Been doing that, all my adult life.

Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a number of its components are. It's still "under wraps."

[grepfru_it]

I hear you, but this problem becomes exponentially harder as your engineering org grows.

I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up my code review denying the PR.

If you are a developer on a team and want your codebase to be high quality, you end up no longer writing the code and instead spend all of your time gatekeeping via code reviews. This leads to burn out.

[gkrimer]

Please come work at Google! This place has the best overall code quality I have ever seen. That's not to say it's always great or bug-free, but it is almost always well maintained. There is very little dead code. Giving and receiving high-quality code reviews is the norm.

[ChrisMarshallNY]

That’s one company that would almost certainly not have me, but I very much appreciate the thought.

Apple also displays extremely high quality code, in the areas that are exposed to the public.

I have not seen too much Adobe code, but I’m told you can eat off the Photoshop codebase.

For myself, I need to keep my scope fairly humble, but I get great joy from it.

It sounds like a gratifying environment. Good show!

[grepfru_it]

Hey, I found your email on another thread.. I will reach out!

[ChrisMarshallNY]

Yeah. It can be a real challenge, ensuring quality on a team.

The obvious answer, is to hire experienced, skilled, capable engineers, and instill in them, the same reverence for Quality that you have.

Like I said, Quality is expensive. Very few companies like to pay the premium.

[grepfru_it]

This does not work at scale. My company does pay the premium and a lot more.

[ChrisMarshallNY]

It does, but it ain't easy. I worked for a company that did it at scale.

[stopnamingnuts]

I wonder if the nuance being identified by the other commenters might be the tragedy of the commons that can play out in collaborative settings. I'm right there with you, btw. Mine is also a non-sexy, non-commercial app and I'm happily a one man band. But a younger me, a junior member of a team, under pressure without close supervision would probably commit a certain amount of half baked spaghetti and be part of the governance problem.

[ChrisMarshallNY]

Yup.

It's not exactly a "one-man show," but I'm the chief architect, and the only one developing one of the three servers the app uses (I was also the original architect for another server, that is now being run by a different open-source team), I am also the only one developing the native iOS application. I may be writing some adjunct apps, once the main one has been released (like Watch, Mac and TV apps).

But we're a team. It's a 501(c)(3), with a mission to Serve a specific demographic. We have the advantage of being intimately familiar with the demographic. So far, we haven't had to shell out much. If they decide to write an Android version, then it may take some extra dosh. The good news is, the app is in "constant ship" state, so asking for funding is fairly straightforward. We just need to loop the person into the TestFlight group, and Bjørn Stronginthearm is your uncle.

[umvi]

It's easy to make high quality software as a team of one - you never have to compromise, after all. You are basically a god of the project. When working on a large team though you have to make all sorts of trade offs at all sorts of levels and it's way harder to produce high quality software because you are no longer a god that controls every single aspect of the project.

[waynesonfire]

I don't buy it. You don't have to own the _ENTIRE_ application to be a developer of one. I've seen many developers that were solely responsible for a specific feature and shipped what I'd consider poor quality.

Large software project, whether you're a developer of one or a team (and probably more commonly occurs in a team since it's large) will have warts. It's harder to manage complexity as the projects size increases since it accumulates and it accumulates fast.

[stavros]

> I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."

What happens if you release it and it turns out that nobody likes it? I'd have preferred to spend a month releasing a lower-quality app, and then spent 11 months improving it (while people use it and I learn more about what they want) rather than take a year releasing a high-quality app nobody wants to use.

This assumes you aren't just building it for fun, though, in which case building it is the point, and you don't even need to release it afterwards.

[ChrisMarshallNY]

You are correct, and that's the classic rationale for "MVP."

But I also follow a development methodology that I call "paving the bare spots."[0] It adjusts the design, as the project progresses. Not for the faint of heart. It means that I may toss out a month's work, because it does not fit the user experience (which is under constant revision). We have also made a couple of major pivots, during the project, to fit new realities.

I have probably tossed out three months' worth of work, as the project has progressed. Happy to do so. The best code, is the code I don't write.

The nice thing is, is that the product is constantly at "ship" Quality. Makes demos, user testing, and begging for money, easier.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

[onion2k]

Professional developers should strive to write the highest quality code they can given the constraints of the project. That's pretty much a given. I'm only arguing that customers don't seem to care, not that we shouldn't care.

[ChrisMarshallNY]

Exactly.

I read a book, where one of the characters is a smith. It has this exchange, between him, and another character:

    "Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing.
    "But that piece goes underneath," Garion said. "No one will ever see it."
    "But I know it's there," Durnik said, still smoothing the metal. "If it isn't done as well as I can do it, I'll be ashamed every time I see this wagon go by -and I'll see the wagon every day.”

[mananaysiempre]

  In the elder days of Art,
    Builders wrought with greatest care
  Each minute and unseen part;
    For the Gods see everywhere.

(from Longfellow, The Builders, 1850)

I’m not sure to which extent I agree with this piece’s medieval outlook of seeking and expecting perfection in the past, not in the future, but it doesn’t detract from the quality of this piece of writing. (Same for Tolkien, for example.) (And the poem actually talks about improving on the past, not venerating it; citing this part in isolation is a bit misleading.) (Now that I’m comparing these two quotes, the difference between “because the gods will see” and “because you’ll know it’s there” is... probably not worth overanalyzing, but at the same time intensely amusing.)

[phlakaton]

I, too, am a firm subscriber to the Goodman Durnik school of development. With an occasional bring-a-flaming-sword-into-a-meeting-room-to-emphasize-your-point twist.

[moonchrome]

One reason I like this kind of work is that it implies when someone spent that much effort on an irrelevant detail they probably paid attention to important parts as well. Not always the case but yeah.

[ChrisMarshallNY]

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

- [Probably erroneously] ascribed to Aristotle

But naysayers will say we are "bikeshedding."

Meh. Whatevs. I do things the way I do.

[cpach]

It’s a paraphrase, but the origin is indeed Aristotle.

http://www.universalethics.org/Ideas/Virtue_as_a_habit.htm