Do companies exist where software isn't done with chewing gum and duct tape?

https://news.ycombinator.com/item?id=14407944

by mlindner • 9 years ago

12 33 9 years ago

news.ycombinator.com

As the title says. Do companies exist where the software they create isn'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't exist and even good process doesn'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.

I'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.

divenorth• 9 years ago

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.

jmnicolas• 9 years ago

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

mlindner• 9 years ago

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

dagw• 9 years ago

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?

wayn33• 9 years ago

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.

BjoernKW• 9 years ago

Banking software more often than not is the epitome of software held together by duct tape. It's a jumble of obsolete systems communicating via convoluted and opaque protocols.

Think COBOL, mainframes, huge, cumbersome application servers and database systems.

It's just that banks have enough money to throw at problems that arise with these systems.

wayn33• 9 years ago

well then, i guess youre right.

afarrell4• 9 years ago

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.

UK-AL• 9 years ago

Yes, but CRUD applications are typically done for small applications on uninteresting problems where people don't really care about code quality. So they have a bad reputation.

The worst CRUD applications, is where they've been extended where they are no longer CRUD but the architecture still assumes CRUD.

wayn33• 9 years ago

maybe i just dont care

maybe it was intentionally conflated to call CRUD usually crappily-built

maybe i dont subscribe to your nomenclature

maybe you can have well-built crud apps (omg I did it again and this time its an oxymoron), but if you pick out a crud app at random, I'll give you 10:1 odds that its code quality is absolute garbage

tbihl• 9 years ago

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

coralreef• 9 years ago

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.

afarrell4• 9 years ago

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.

ubikretail• 9 years ago

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.

afarrell4• 9 years ago

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

random123456• 9 years ago

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

dreistdreist• 9 years ago

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.

ankurdhama• 9 years ago

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).

JoachimSchipper• 9 years ago

Some pointers:

- danluu.com (user luu) on testing in the hardware world (e.g. 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

seanwilson2• 9 years ago

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.

marenkay• 9 years ago

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• 9 years ago

This is the best response.

dakevster• 9 years ago

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 ...)

afarrell4• 9 years ago

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.

brudgers• 9 years ago

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.

AnimalMuppet2• 9 years ago

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.

bfrog• 9 years ago

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.

daxfohl• 9 years ago

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

jbms• 9 years ago

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.

seanwilson2• 9 years ago

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.

Do companies exist where software isn't done with chewing gum and duct tape?

Related Stories