
Do companies exist where software isn't done with chewing gum and duct tape? - mlindner
As the title says. Do companies exist where the software they create isn&#x27;t a series of band-aids, duct tape, and chewing gum? The more I work the more I realize that the concept of good code doesn&#x27;t exist and even good process doesn&#x27;t exist and everyone does their job haphazardly. Is everything really as hopeless as it seems? I keep wondering why I even started in this career.<p>I&#x27;m a perfectionist by nature and all I see are people writing way more code than I do and slapping it all together with a nonsensical speed just to get things out the door.
======
marenkay
Honest advice... the real engineering world is never about perfection. Most of
the time you have a lack of business information, requirements missing, no
test cases, etc.

The bigger the company, the larger chances to see code that is far from
perfection are. Business process and large amount of teams make it harder to
acquire all information needed to engineer things.

Also, most of the time it is about satisfying a customers needs. That is not
about doing it right, it is about making it work.

Companies building solid code exist. They are rare and usually not the ones
making billions in the market.

I find it pretty amusing that people assume Google, Microsoft, etc. would
actually be rock solid as those have a sufficient amount of damaged legacy
code that for thousands of reasons needs to stay broken.

Parting words: ditch perfectionism, embrace the 80/20 percent pattern instead.

~~~
PrimalPlasma
This is the best response.

------
jbms
Recovering perfectionist here. Refocus your perfectionism on doing the most
valuable job for the business, from a business sense. For me, that means doing
half a dozen different job roles (Project management of multiple projects, SW
architecture across multiple projects, Development, Test, Quality control,
Process improvement, Team training) - none of them are done as well as I'd
like if I focused completely on them, but what the business needs is someone
who does them all to a decent standard. It's the perfect balance that's
required, not one area perfect.

I also focus as an architect on splitting up the projects into small modules
that can be developed, unit tested, statically analysed and integration
tested. Those who work on these are being trained up in each stage of the
process and are getting better and better at it - they can't move onto the
next module if the existing one isn't complete, so it spreads out the work
they don't like (or have never devoted the time to learn the skills for) so
it's not left to the end (and then not done). We're building lots of software
components to a very high standard with very little technical debt being
stored or rework being required. My employer's been realising the amount that
quality issues are causing a lot of trouble (delays, costs, etc), so they're
highly supportive of this kind of work and my high standards are appreciated.
I work in embedded software, so software updates in the field are painful,
sometimes embarrassing, and potentially expensive.

------
dreistdreist
Look for companies that maintain a software for decades.

Agencies and fresh startups often optimize for speed, not maintainability. But
there are plenty of companies that optimize for maintainability, you just have
to look for them.

Mentions of code reviews, automatic tests, SOLID, DDD etc are usually good
signs.

------
JoachimSchipper
Some pointers:

\- danluu.com (user luu) on testing in the hardware world (e.g.
[https://danluu.com/tests-v-reason/](https://danluu.com/tests-v-reason/)) and
at Google

\- in general, mature high-quality engineering organizations like Google and
modern Microsoft

\- e.g. Praxis (Google "Tokeneer report") and Galois practice semi-formal and
formal methods to produce useful software

\- e.g. TrustInSoft and seL4 go to full formal verification

~~~
seanwilson
Formal verification is an really interesting and challenging field but it's
worth commenting that it is very expensive and time consuming. It generally
only makes sense right now when bugs can cause serious damage.

------
afarrell
The company I work at right now seems quite good at maintaining solid code
quality. I'm pretty sure the reasons why are:

* A belief that code quality lets us deliver faster in the medium-term

* We start projects by asking "why does this need to be done?" and pushing for a fleshed-out explanation of that. This lets us write less code and do sometimes do projects without writing code. It also reenforces that we are building sonething that we will then need to mainain.

EDIT: * We also follow that up with writing out a 1-2 page document explicitly
outlinibg the scope of the project, the approaches we considered but are not
taking, and the approach we are taking. This helps us keep a 1 week project
from taking 3 weeks.

* Our hiring process includes a take-home coding test and a pair-programming exercise. We explicitly grade these on code quality and testing, so we filter for hires that value these things.

Feel free to email me at amfarrell@gocardless.com if have questions.

------
dakevster
Early on in my career of being a consultant I've came to same realisation. At
the end of the day what is a customer going to complain about more, that the
code base is spaghetti or that a button is in the wrong place?

The problem is worst in certain sectors. For example I've worked in banks
where quick fixes are slapped on top of other quick fixes, often written by
other people which creates on monumental pile of spaghetti, not mention
they're still using legacy mainframes from 40 years ago. But you have to
remember that the customer only cares about money generation, they couldn't
give two hoots about the elegancy of your code. But if it works it works.

On the flip-side have worked for startups and I am the CTO of a startup and I
can safely say we prioritise speed of features over maintainability and
elegancy. We do what we can now but you have to remember that products and its
requirements are ever changing and can never be 'perfect'.

Reid Hoffman, the founder of LinkedIn famously said:

'If you are not embarrassed by the first version of your product, you’ve
launched too late.'

There is no such thing as perfect code or perfect process, there are spectrums
in between. At the end of the day you have to maintain focus on what the
customer/users want to see. That's not to say you should roll over for all
customer demands, but you should always keep that in the back of your mind.

The other thing is that what you may regard as good code may not be what it
others see as good code, it's subjective.

My advice would be if you want to create what you regard to be perfect code
then you should work for yourself, whether that's creating your own open
source Github repos or trying to start your own company. Otherwise embrace the
imperfections of IT and indeed the world we live in see it as challenge to
make perfect (too deep? I'll see myself out ...)

------
seanwilson
To pile on with the comments about avoiding perfectionism and having business
sense, I've seen projects and teams go under because they tried to apply every
technique they'd heard of that could improve quality control without taking
the project budget into consideration.

Cutting corners too much is equally as bad as being a perfectionist as well.
Perfectionism might even be worse because you'll probably never finish
anything.

Software can always be made better. The important development skill is knowing
what's good enough so you're not burning time for little benefit.

------
bfrog
Speed to market and quality control intersect at different points for
different products.

Killing someone by blasting them with Xrays is a very costly error, better to
spend more (time is money) on quality. An html form failing in some obscure
way for 1 out of every 1000 people resulting in a small $ loss isn't too vital
out of the gate and acceptable if it can easily be fixed after product launch
without a bunch of hassle. An app crashing in an enterprise that's locked in
to some lame contract is even less vital. Like they paid some contract firm to
one off some software with no real discussion of support.

------
brudgers
Thinking in terms of companies means that the business interest has to align
with the particular measures of software quality that interest you. Reframing
the employment search from companies to organizations may open up a different
set of options ranging from government to departments within institutions to
teams within an enterprise. But even in terms of companies, looking at those
where software quality is critical to the business (e.g. high frequency
trading or google) might focus the search.

Good luck.

------
ubikretail
What people might be missing is that you don't do anything "lean" without
refactoring sprints. So as you grow, you keep considering the macro structure.
If not, you should use TDD at least.

Nevertheless, validation is key, from an executive POV. It makes sense that
things are dirty in the beginning, but they should start being encapsulated,
object oriented, properly interfaced, etc. as soon as you feel in need for a
second programmer.

~~~
afarrell
Even with TDD, you need refactoring sprints. Occasionally, you find your tests
get in a state where they need refactoring.

------
random123456
Some kind of sarcasm with truth inside.

Only you and your colleagues will see your code, your product will see all
others. If you want to satisfy your colleagues and yourself with clean/elegant
code, go and code side project only for them. If you want to ship real
product, then ship it even though it contains lots of shit code. Thats one of
the reasons why people just code, not make it clean at first

------
ankurdhama
You never get "fixed" and completely defined requirements. Every software
project evolves over time and this evolution basically means "Hey we have
modified the problem and now you have to fix the existing algorithm such that
is works for new problem" (AKA not coming up with new algorithm from scratch
for updated problem).

------
AnimalMuppet
Yes, they exist. Maybe not up to the standards of a perfectionist, but much
better than garbage, created with some professionalism.

If you insist on the standards of a perfectionist, though, you may be forever
disappointed.

------
divenorth
I just finished reading Lean Startup. One big concept is why spend lots of
time perfecting a program that nobody will even use. Seems to be the current
trend. And honestly after reading the book it makes sense.

------
coralreef
Maybe join an open source/non-profit software company (like Mozilla).

I don't know that those places have better code, but probably less pressure to
ship product to satisfy customers.

~~~
afarrell
I used to work at a company whose main product was built on top of an open
source project they also were the sole maintainers of. The code for that open
source project was not great and, when I and a more senior engineer wanted to
refactor it to make it cleaner and add functionality, we got pushback of the
form "The current codebase is already tested. If you change it, it could
introduce bugs." Meaning that users had "tested" it by using it and reporting
bugs that then got fixed. I was so stunned by that argument that I didn't know
what to say at the time, but this is bad because:

1) Many users won't report bugs because that takes effort and they just want
to solve their problem

2) Users won't report when the UX is bad.

3) Not being able to change a product to add clear business value...prevents
you from adding value. This is bad because it makes it harder for your product
to help the business grow and solve more problems.

4) Not being able to change the code to be cleaner and more well designed
makes it hard to add more maintainers and to add or remove features.

I don't know how to explain why you should want to be able to change your
product. I've only moved on to an org which had a much different approach to
technical debt.

------
jmnicolas
Look in the aerospace industry, things may be better there.

~~~
mlindner
That's also exactly what I don't want. It's more paperwork than code in such
places all full of rigorous validation.

~~~
dagw
How do you expect a company to keep to their code to the highest standard
without continuously and rigorously validating that the code is actually up to
standard?

~~~
AnimalMuppet
mlindner didn't ask for "the highest standards", though - just for "not
trash".

You do have to ask whether the code does what it's supposed to do. What is
your objective evidence that it does so? You need that.

But you don't need aerospace standards unless you're critical infrastructure.
If you're writing a web app? Not so much. You'd still like to be able to not
throw up when you look at the code, though.

~~~
probinso
It sounds like you are asking rhetorical questions

------
daxfohl
No, corporate notwithstanding, even lots of purely logical things still need
some form of ugly hackery to get it to work right.

------
wayn3
google, banking, surgical robots, etc.

look at companies that kill if they fuck up. dont count on random crup web app
shop to give a crap about clean code.

~~~
afarrell
> crud web app shop

CRUD != crud

I don't know if you are making this error, but I it all the time on
/r/cscareersquestions and it is a foolish conflation.

crud: crappily-built product

CRUD: a set of UI operations on records in your data model.

You can totally have a well-built CRUD app maintained by a team that cares
about code quality.

~~~
tbihl
Alternatively,if we're being pedantic, we can go to the original definition,
Chalk River Unidentified Deposit (later determined to be activated corrosion
products.)

~~~
jamessb
This seems to be a backronym, rather than the word's actual etymology [1].

[1]: [https://public-blog.nrc-gateway.gov/2015/03/31/crud-
another-...](https://public-blog.nrc-gateway.gov/2015/03/31/crud-another-
acronym-bites-the-dust/)

