Do companies exist where software isn't done with chewing gum and duct tape?
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.
33 comments
[ 2.6 ms ] story [ 75.1 ms ] threadYou 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.
look at companies that kill if they fuck up. dont count on random crup web app shop to give a crap about clean code.
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.
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.
The worst CRUD applications, is where they've been extended where they are no longer CRUD but the architecture still assumes CRUD.
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
[1]: https://public-blog.nrc-gateway.gov/2015/03/31/crud-another-...
I don't know that those places have better code, but probably less pressure to ship product to satisfy customers.
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.
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.
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
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.
- 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
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.
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 ...)
* 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.
Good luck.
If you insist on the standards of a perfectionist, though, you may be forever disappointed.
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.
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.
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.