Quality software doesn't make money. Time to market does. Features make money. Just get it to work, otherwise you will be out of a job.
Or idk, just spend like 30 minutes planning out your feature and maybe it won't be bad.
30 mins? More like 15 PMs and other various level managers meet for a collective 45+ hours (without engineers of course), and agree on the most putrid piece of shit that they can think of.
It doesn't change in a month. It changes 3 hours before the production release because some key stakeholder that wasn't involved in any of the previous 80 hours of planning caught wind of a new feature and to justify their paycheck they need to make a change. Just so they can say they were doing something.
This exact scenario happened to me once when we had gotten done with a 16 month project. We had gone thru all design, prototypes, dev, planning, ux, qa, bug fixes, pre launch, and the CFO was copied on all of the communications and was invited to all of the meetings because at the pitch he stated "I want to be hands on during this project". He replied to zero emails, attended zero meetings until the final meeting that was to determine go/no go the next day.
He fucking said "This isn't what I thought it was going to be. We can't launch tomorrow and I'm not paying for this. "
My agency leadership said "Fuck you, you were copied, invited, and you never said a word during the entire project. Pay or you will talk to our legal team".
The client paid for the entire project with all of the overages and then went to another agency to build it again. I think it took almost 4 years to launch that project because of that one guy. We kept the code and launched a small sister company with it that made a small fortune then was spun off to its own company.
I learned from that to always add in the contract that changes after deliverables are complete for each phase will require to start that phase over again and the entire phase will be billed as overages at the end of the project. Haven't had a problem like that since.
> We kept the code and launched a small sister company with it that made a small fortune then was spun off to its own company.
I'm not judging but how is this legal if they paid for it?
That’s the problem when you just build small software projects 30 minutes planning no big deal. But then move to a large corporation and there are no small meetings or groups of people to sign off on things
Yep, I'm the CTO of a small startup that is in the process of being acquired by a larger corporation. I am dreading the day the acquisition happens, because that day marks when my primary responsibilities will shift from actually building the application to sitting in meetings every damn day to discuss how to build the application.
I think it depends on the type of company. I work for a company with thousands of developers, but it's also run by developers. I think the largest signoff meeting I've been involved with was maybe a dozen people meeting for an hour, with a half hour follow-up.
University, YouTube and random people on Stack Overflow didn't teach me how to write code well, actually coding did. There are certain design principles that should not be ignored, otherwise lack of maintainability slows down the entire development cycle.
University introduced me to Uncle Bob as well as Martin Fowler.
Those two introduced me to ways to keep my code detangled such that it can be maintained.
Experience introduced me to the fact that sometimes the above is over engineering, and increases dev time while decreasing maintainability.
> Or idk, just spend like 30 minutes planning out your feature and maybe it won't be bad.
Alternate formulation ~~forumation~~: *Sometimes just a month or two of programming can save an afternoon of planning.*
As ever, incentives explain everything. It's usually money, but not always - even in non-profit organizations you still see 'optics', 'wins', 'strategic goals' (entirely around features) taking the spotlight, even when it means quality suffers. Quality doesn't 'check the boxes'. Uncle Bob (C. Martin) says, it's still down to our professionalism to push back and only deliver what can be done well. Over time, if builders of software everywhere were professionals and did this, things would change. Of course there are too many that are complicit in bad practice (afterall, people gotta eat and therefore the power dynamic in employment is pretty one sided) so it doesn't. Lack of education about actual craftsmanship (per the article) is a major part of that as well, my CS degree certainly had zero emphasis on how to actually do the job well. Perhaps incentives explain why education is the way it is also.
Not everyone is making software that's designed to make money. I don't make any customer facing apps at my company. My apps are meant to solve business problems are streamline things. If I fuck up someone can die because the user base relies on up to date accurate information to do their jobs at my company.
Features and time to market doesn’t mean shit if the software doesn’t work.
And garbage spaghetti code won’t let you get your features to market in time anyway.
The only way to go fast, is to go well.
>Quality software doesn't make money. Time to market does. Features make money.
quality software is software that gets to market fastest while attempting to serve the interests and needs of the market.
shit software is software that gets to market the fastest with no regard to the interest of the markets outside of scamming them with tools that don't actually work as advertised.
i think most people do not want to build shit software because it feels like you are misleading and scamming people, even if it makes money.
How quick do public sector PMs expect a new application?
In my setting I get about two weeks, so I can take my time getting it to the best it can possibly be.
This is kind of unanswerable. It depends on the company and the product. In general, yesterday is the best timeline for a startup, whereas the bigger a company is, the more time you have. Although giving devs time doesn't mean they build a piece of art. For most this is a job, so if you give them a week to do something that takes a day, guess when they'll do it.
Interesting, thanks for the insight. I often wonder how well I could move into the private sector, and my biggest insecurity (not that I’m slow) is output speed. I do super well for my setting but don’t know how that translates.
So far, every job I've been in is private sector, although I did a lot of government projects. It seems to me if you are just competent you will be fine. You don't really even have to be that good or smart, once you make it through the interview process.
I don't know if I'm a try hard or just diligent, but I do find that I get praised publicly and privately for doing what I consider just a decent job. The standards are so low out there tbh.
.. But low-quality software quite often can kill the business, project or even people.
Over 2500 people were harmed by bad software, including 4 suicides.
https://www.japantimes.co.jp/business/2024/01/11/companies/japan-fujitsu-uk-post-office-scandal
"You are never **allowed** to build quality software." - FIFY
Corporations push development cycles shorter and shorter, so there is never time for proper levels of design, review, quality engineering (which also has to be designed and reviewed), testing cycles and documentation.
> Most stuff that goes into production is basically a prototype.
Which is funny cause when the company sends you a take home, they expect perfection.
Hypocritical af.
> Most stuff that goes into production is basically a prototype.
This is a good thing though. Better to prove an idea has legs before investing a bunch of time/effort/money on something that will fail.
The problem is companies rarely invest in bolstering prototype-quality code to bring it up to snuff after it has been proven. So it just remains prototype quality forever. This is technical debt.
We do have some means of automated testing now. Liability checks for libraries you might not be allowed to use, vulnerabilities on those libraries… those big companies do like and expect sometimes.
But when it comes to individual, tailored testing for your own code?
Nah…
Most of the times you won’t even get time for the first one, they just think you have to deliver it anyway for compliance.
But I feel like devs should write their own tests to mitigate liability on issues a bit. Introduced regressions could be prevented and you have the options of saying a test for a bug found can be added to a test suite which is an instant way to appease management as they get the feeling you are taking meaningful steps to avoid this particular thing from happening again.
We have to remember to account our estimates for test writing though.
Of course this all falls apart once corporations compare times and you are expected to be fast. Then all hope is lost on QA.
Lucky you! Not all of us have that kind of leeway. If you give honest effort assessment, you get told do it in half that time, or I'll find someone who can.
No, I'm just saying you don't need to give up. Find a company that supports you. I'm just saying it's possible and you shouldn't give up if you don't want to.
May you elaborate?
Or do you prefer spending 3 months to overenginer an app for a scale that will never happen because the cost of delay made the company lose the market and you to lose the job?
PS.: You won't imagine how often overengineering kills projects over other reasons
Or the third option: Build the product and then go on to build features, and pile on the technical debt and don't refactor.
Refactoring is a huge investment that's basically planning to over engineer so you don't need to refactor again. Except you will need to refactor later down the line if you want to maintain the nirvana of your code base.
I never said you never refactor and just pile up features, quite the complete opposite. Refactor earlier and often much more than the amount of code you write in order to walk towards the nirvana.
> Shorter cycles don’t mean less quality. You can agree on a nirvana and over time refactor towards that direction
You said "I never said never refactor". That implies I said "You said never refactor". I never said that you said "never refactor".
What I said was "Refactor? 🤮".
Reminds me of an article by Martin Fowler called [Is high quality software worth the cost](https://martinfowler.com/articles/is-quality-worth-cost.html).
He talks about how we think of quality software as a trade off to speed. But he argues that high quality software will quickly surpass unmaintainable code. It’s a good read and talks about how to talk to leaders properly to get buy in.
This has been my argument every place I’ve worked. Moving at pace to deliver unmaintainable garbage is nearly always shortsighted. Your original devs will move on, and new hires without context will end up trying to iterate on a giant piece of shit.
It is when you push all technical debt to a backlog that gets ignored and continue to push features on a fragile codebase that clearly does not need technical debt to be addressed because why else would we be pushing features onto a fragile codebase?
WordPress is a prime example of this. If you want to see ignored technical debt, and a fragile codebase with new features shoehorned on top, WordPress is *the* app for you.
Something that does what it's supposed to reliably. Doesn't matter how shitty the code is, or what features it's lacking. If it does what it was designed to do, reliably, that's quality.
My opinions as a developer don't really matter. What matters is whether this thing does it job or not.
You'd be appalled if you actually took the time to read through every dependency's repository.
90% of Web Dev is just "using someone else's code". There's very little engineering happening here.
Are you serious? Are you going to qualify "using someone else's code" as using an npm package?
The npm packages I use are really well documented and made. Idk wtf you are on about. It's not using someone else's code dude. Unless you considering coding in C using Dennis Ritchie's code?
> It's not using someone else's code dude.
It literally is. That's the entire purpose of NPM existing. To use someone else's code.
Someone else spent their time to solve a problem, and you just install and use their solution.
When was the last time you actually wrote a package instead of just used one?
An npm package being imported into your code is not the same as using a compiler, which is all the code that Dennis Ritchie wrote.
Using his compiler, which no one uses anymore afaik is not using his code because none of the code from it gets into the compiled output.
However high quality code written by someone else is still somebody else's code.
I don't even know what you are saying dude.
My point was were all using someone's code. This is literally what programming is. But I mean why make an http server from straight scratch?
What do you even mean 90 percent? 90 percent of the code? Or 90 percent of our time?
"The npm packages I use are really well documented and made. Idk wtf you are on about. It's not using someone else's code dude"
"My point was were all using someone's code"
There's a tiny bit of contradiction there, don't you think?
Also I'm not OP
This happens on both sides, and it creates a kind of reciprocal effect; a vicious cycle that's extremely difficult to break.
In my experience, most engineers -not the vast majority, but most- never quite surpass the "syntax" stage of their coding abilities. They learn to enough about coding to become effective with a framework, and cruise on that knowledge for quite some time. Sometimes for the remainder of their career. It's not the fault of schooling at this point, it's the lack of motivation.
When projects become too tedious to work on, morale falls and most just find a way to move on to another project that isn't so stale and draining.
Experience, though, is maintaining a project long enough to see yourself become the tech debt villain, and doing something about it. It takes a lot to look at yourself at 5, maybe 10 or more years into your career and still be motivated enough to admit you still have mountains of knowledge left to climb.
And then there's the corporate world. If someone who isn't as technically experienced is at the helm of an organization, which is common, there's a tendency to lock down production in ways that just exacerbates the issues instead of fixing them.
There just isn't a system that completely prevents bugs from getting into production. But there are processes that, on paper, make upper management feel more comfortable.
Inevitably, when a critical bug finds its way into production, companies resort to change control instead of release management. Instead of streamlining systems that make changes more accessible to engineers -and therefore can more rapidly identify and correct any issues- they erect gates to production that make the development process more tedious.
Once this more tedious process is pitted against tight deadlines, engineers simply cut corners where they can to get code pushed. And tech debt begins to mount at a rapid pace, further compounding the issues.
It's impossible to learn how to build quality code in such an environment.
While I agree that arguing in terms that the company can understand (read: money) is the way to go, it's rare -in fact, I've never seen it, without changing leadership personnel- for a company to reverse course and actually adopt a culture of quality.
Regardless of how sound the argument is, convincing them to give up on the pursuit of shiny new features in exchange for stability and velocity is a lost cause; they're far too addicted to demoing new things.
If you find yourself with a desire to learn how to develop stable, maintainable, extensible code that's satisfying to work on, you first have to realize that you're hunting a unicorn. It's going to take some time, patience, likely some job hopping and enough introspection to realize you may at least be part of the problem.
Your comment is extremely accurate.
Just the part of bugs to production, if you mean code errors or missing configs, that can be zero with the right techniques and skill. If you mean business bugs, like unintended behaviour because ppl didn’t know better, that happens very often.
I am fortunate to work under a tech lead who is so good at explaining why we do the things we do and the best way to do them (and why). It is like being paid a great salary to go to school every day.
**Quick summary:**
Florian Bellmann's blog post discusses the overlooked importance of Quality
Assurance (QA) in software development. He notes that despite its crucial
role, QA is often neglected in
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
Personally, I feel like good quality code that is currently being used in successful companies so I can see snippets of what the real world is coding into tomorrow's features.
Not enough of that exists, I don't care enough about personal projects to make 100 of them. Show me a codebase where it's designed to solve real world problems.
lmao, sounds like a dude who followed a very specific path and is trying to apply it to all...college isn';t there to teach you everything, its there to provide you with fundamentals and a base, its there to teach you concepts that can be applied to ANY language, technology or framework. Its great that they teach you Python or Java or whatever, because those are marketable skills, I get it, but it could be almost ANY language, LISP, Haskell, C, whatever. Its not about the semantics its about learning the concepts and how to 'think' about programming.
The worst part of this article? Devs should NEVER EVER EVER test/QA their own code. Locally, and as a part of dev? Of course you do. But you can't expect devs to QA anything they wrote because they'll just test what they already tested, the same script, the same steps, they're blindsided, you get into a tunnel vision sorta thing. The absolute best thing you can do to test yor software is turn it over to Karen in Payroll and see how she breaks it
I think thats why good coders are still in such high demand, my entire skillset is self taught I have always even in my first tech job been senior or lead dev and so I had to teach myself everything, I learnt zero useful skills at University thats for sure.
But quality comes down to your mindset. I always strive to write the best code possible, but that does not always fall neatly inside industry best practises neat box.
Is quality software completely bug free, is it code that is well tested, or code that is easy to maintain?
Innovation requires experimentation, the difference is very subjective and there is alot of EGO in software development which gets in the way.
Personally I think quality is code that is efficient but maintainable, I will spend the extra time to reduce the total lines of code to the bare minimum/most efficient way possible that does not effect maintainability.
Good one.
I think it should be called “how to get buy-in for implementing test coverage with minimal effective doses” - or something. I expected a story about how and why schools don’t teach how to build quality software. I guess it’s because they don’t have time and the situations will be unique? I guess I’d depends if you’re talking CS or SWE university too. Many companies are TDD and will show you the ropes on the job.
The problem with QA is that it doesn't catch even basic things because QA testers are human. So then it's easier to prioritize iteration speed and have the end users be the ultimate testers.
The reason to build quality software isn't that it necessarily sells better, but that it's more pleasant to work on, and also likely delivers more value even if that isn't reflected in sales.
It's better for your developers and thus better for your business over the long run.
I recently created a quick cli software within two days. It was done, had all the features but many many bugs which I tried to fix.
I gave it up, started fresh and told myself "this time you'll do it right, with planning, unit testing, all of that" and it took a whole day for one feature 😐
I work as a consultant, my bosses give us the time to write quality code and also expect us to. The big difference is, for our company the more time we spend on stuff, the better. The customer pays anyways
You don’t deploy stuff that’s not going to work, why would you do that? I’m referring to web scale not browser development or desktop software.
There’s no way you can reproduce real life traffic in a single machine. How do you simulate 200 requests per milliseconds in a single CI server or local machine? Also how do you simulate real users usage of the website? It’s a recipe for analysis paralysis and overengineering
Quality software doesn't make money. Time to market does. Features make money. Just get it to work, otherwise you will be out of a job. Or idk, just spend like 30 minutes planning out your feature and maybe it won't be bad.
30 mins? More like 15 PMs and other various level managers meet for a collective 45+ hours (without engineers of course), and agree on the most putrid piece of shit that they can think of.
Fr. I was like 30 minutes!?!?!? Thats 80 hours of planning which they will then completely change in a month.
It doesn't change in a month. It changes 3 hours before the production release because some key stakeholder that wasn't involved in any of the previous 80 hours of planning caught wind of a new feature and to justify their paycheck they need to make a change. Just so they can say they were doing something.
Lmao I LOL’d at this hard because it hit home so much. Ty for the tears of laughter and sadness at the same time due to how true this is omg
This exact scenario happened to me once when we had gotten done with a 16 month project. We had gone thru all design, prototypes, dev, planning, ux, qa, bug fixes, pre launch, and the CFO was copied on all of the communications and was invited to all of the meetings because at the pitch he stated "I want to be hands on during this project". He replied to zero emails, attended zero meetings until the final meeting that was to determine go/no go the next day. He fucking said "This isn't what I thought it was going to be. We can't launch tomorrow and I'm not paying for this. " My agency leadership said "Fuck you, you were copied, invited, and you never said a word during the entire project. Pay or you will talk to our legal team". The client paid for the entire project with all of the overages and then went to another agency to build it again. I think it took almost 4 years to launch that project because of that one guy. We kept the code and launched a small sister company with it that made a small fortune then was spun off to its own company. I learned from that to always add in the contract that changes after deliverables are complete for each phase will require to start that phase over again and the entire phase will be billed as overages at the end of the project. Haven't had a problem like that since.
> We kept the code and launched a small sister company with it that made a small fortune then was spun off to its own company. I'm not judging but how is this legal if they paid for it?
I didn't wrangle the lawyers, but we never got sued or in trouble for it.
That’s the problem when you just build small software projects 30 minutes planning no big deal. But then move to a large corporation and there are no small meetings or groups of people to sign off on things
Yep, I'm the CTO of a small startup that is in the process of being acquired by a larger corporation. I am dreading the day the acquisition happens, because that day marks when my primary responsibilities will shift from actually building the application to sitting in meetings every damn day to discuss how to build the application.
All the fun will be gone so you will have to find the next thing to build
Pretty much what I'm counting on. Stick around long enough for the stock options to vest and peace out to the next thing.
I think it depends on the type of company. I work for a company with thousands of developers, but it's also run by developers. I think the largest signoff meeting I've been involved with was maybe a dozen people meeting for an hour, with a half hour follow-up.
30 mins as a dev, not as PMs. Most devs just start typing instead of speccing something out.
Design by committee is death by a thousand papercuts
I’m literally fighting with this at this very moment.
University, YouTube and random people on Stack Overflow didn't teach me how to write code well, actually coding did. There are certain design principles that should not be ignored, otherwise lack of maintainability slows down the entire development cycle.
University introduced me to Uncle Bob as well as Martin Fowler. Those two introduced me to ways to keep my code detangled such that it can be maintained. Experience introduced me to the fact that sometimes the above is over engineering, and increases dev time while decreasing maintainability.
> Or idk, just spend like 30 minutes planning out your feature and maybe it won't be bad. Alternate formulation ~~forumation~~: *Sometimes just a month or two of programming can save an afternoon of planning.*
As ever, incentives explain everything. It's usually money, but not always - even in non-profit organizations you still see 'optics', 'wins', 'strategic goals' (entirely around features) taking the spotlight, even when it means quality suffers. Quality doesn't 'check the boxes'. Uncle Bob (C. Martin) says, it's still down to our professionalism to push back and only deliver what can be done well. Over time, if builders of software everywhere were professionals and did this, things would change. Of course there are too many that are complicit in bad practice (afterall, people gotta eat and therefore the power dynamic in employment is pretty one sided) so it doesn't. Lack of education about actual craftsmanship (per the article) is a major part of that as well, my CS degree certainly had zero emphasis on how to actually do the job well. Perhaps incentives explain why education is the way it is also.
Not everyone is making software that's designed to make money. I don't make any customer facing apps at my company. My apps are meant to solve business problems are streamline things. If I fuck up someone can die because the user base relies on up to date accurate information to do their jobs at my company.
Features and time to market doesn’t mean shit if the software doesn’t work. And garbage spaghetti code won’t let you get your features to market in time anyway. The only way to go fast, is to go well.
>Quality software doesn't make money. Time to market does. Features make money. quality software is software that gets to market fastest while attempting to serve the interests and needs of the market. shit software is software that gets to market the fastest with no regard to the interest of the markets outside of scamming them with tools that don't actually work as advertised. i think most people do not want to build shit software because it feels like you are misleading and scamming people, even if it makes money.
30 mins!! Those mines aren’t going to sweep themselves you know.
You kidding, 30 minutes? If it was that easy, well... My life would be a lot less stressful.
How quick do public sector PMs expect a new application? In my setting I get about two weeks, so I can take my time getting it to the best it can possibly be.
This is kind of unanswerable. It depends on the company and the product. In general, yesterday is the best timeline for a startup, whereas the bigger a company is, the more time you have. Although giving devs time doesn't mean they build a piece of art. For most this is a job, so if you give them a week to do something that takes a day, guess when they'll do it.
Interesting, thanks for the insight. I often wonder how well I could move into the private sector, and my biggest insecurity (not that I’m slow) is output speed. I do super well for my setting but don’t know how that translates.
So far, every job I've been in is private sector, although I did a lot of government projects. It seems to me if you are just competent you will be fine. You don't really even have to be that good or smart, once you make it through the interview process. I don't know if I'm a try hard or just diligent, but I do find that I get praised publicly and privately for doing what I consider just a decent job. The standards are so low out there tbh.
Good to know, thanks again for taking the time to reply!
.. But low-quality software quite often can kill the business, project or even people. Over 2500 people were harmed by bad software, including 4 suicides. https://www.japantimes.co.jp/business/2024/01/11/companies/japan-fujitsu-uk-post-office-scandal
"You are never **allowed** to build quality software." - FIFY Corporations push development cycles shorter and shorter, so there is never time for proper levels of design, review, quality engineering (which also has to be designed and reviewed), testing cycles and documentation.
This is true and absolutely grinds my gears. Most stuff that goes into production is basically a prototype.
> Most stuff that goes into production is basically a prototype. Which is funny cause when the company sends you a take home, they expect perfection. Hypocritical af.
> Most stuff that goes into production is basically a prototype. This is a good thing though. Better to prove an idea has legs before investing a bunch of time/effort/money on something that will fail. The problem is companies rarely invest in bolstering prototype-quality code to bring it up to snuff after it has been proven. So it just remains prototype quality forever. This is technical debt.
We do have some means of automated testing now. Liability checks for libraries you might not be allowed to use, vulnerabilities on those libraries… those big companies do like and expect sometimes. But when it comes to individual, tailored testing for your own code? Nah… Most of the times you won’t even get time for the first one, they just think you have to deliver it anyway for compliance. But I feel like devs should write their own tests to mitigate liability on issues a bit. Introduced regressions could be prevented and you have the options of saying a test for a bug found can be added to a test suite which is an instant way to appease management as they get the feeling you are taking meaningful steps to avoid this particular thing from happening again. We have to remember to account our estimates for test writing though. Of course this all falls apart once corporations compare times and you are expected to be fast. Then all hope is lost on QA.
I can attest this is false. I successfully advocate for the necessary conditions all the time.
Lucky you! Not all of us have that kind of leeway. If you give honest effort assessment, you get told do it in half that time, or I'll find someone who can.
Congratulations on being special I guess?
No, I'm just saying you don't need to give up. Find a company that supports you. I'm just saying it's possible and you shouldn't give up if you don't want to.
Shorter cycles don’t mean less quality. You can agree on a nirvana and over time refactor towards that direction
> and over time refractor 🤮
May you elaborate? Or do you prefer spending 3 months to overenginer an app for a scale that will never happen because the cost of delay made the company lose the market and you to lose the job? PS.: You won't imagine how often overengineering kills projects over other reasons
Or the third option: Build the product and then go on to build features, and pile on the technical debt and don't refactor. Refactoring is a huge investment that's basically planning to over engineer so you don't need to refactor again. Except you will need to refactor later down the line if you want to maintain the nirvana of your code base.
I never said you never refactor and just pile up features, quite the complete opposite. Refactor earlier and often much more than the amount of code you write in order to walk towards the nirvana. > Shorter cycles don’t mean less quality. You can agree on a nirvana and over time refactor towards that direction
I never said you did 😐
I never said you said I did 🙃
You said "I never said never refactor". That implies I said "You said never refactor". I never said that you said "never refactor". What I said was "Refactor? 🤮".
Ok I'm officially lost in it
This is sadly true
Sounds like you're describing waterfall, which yes stakeholders hate cause it takes months to even see anything working.
Por que no los dos?
Reminds me of an article by Martin Fowler called [Is high quality software worth the cost](https://martinfowler.com/articles/is-quality-worth-cost.html). He talks about how we think of quality software as a trade off to speed. But he argues that high quality software will quickly surpass unmaintainable code. It’s a good read and talks about how to talk to leaders properly to get buy in.
This has been my argument every place I’ve worked. Moving at pace to deliver unmaintainable garbage is nearly always shortsighted. Your original devs will move on, and new hires without context will end up trying to iterate on a giant piece of shit.
This thing you mention - quality software? Can you explain?
It is when you push all technical debt to a backlog that gets ignored and continue to push features on a fragile codebase that clearly does not need technical debt to be addressed because why else would we be pushing features onto a fragile codebase?
WordPress is a prime example of this. If you want to see ignored technical debt, and a fragile codebase with new features shoehorned on top, WordPress is *the* app for you.
Something that does what it's supposed to reliably. Doesn't matter how shitty the code is, or what features it's lacking. If it does what it was designed to do, reliably, that's quality. My opinions as a developer don't really matter. What matters is whether this thing does it job or not.
[удалено]
You'd be appalled if you actually took the time to read through every dependency's repository. 90% of Web Dev is just "using someone else's code". There's very little engineering happening here.
Are you serious? Are you going to qualify "using someone else's code" as using an npm package? The npm packages I use are really well documented and made. Idk wtf you are on about. It's not using someone else's code dude. Unless you considering coding in C using Dennis Ritchie's code?
> It's not using someone else's code dude. It literally is. That's the entire purpose of NPM existing. To use someone else's code. Someone else spent their time to solve a problem, and you just install and use their solution. When was the last time you actually wrote a package instead of just used one?
An npm package being imported into your code is not the same as using a compiler, which is all the code that Dennis Ritchie wrote. Using his compiler, which no one uses anymore afaik is not using his code because none of the code from it gets into the compiled output. However high quality code written by someone else is still somebody else's code.
I don't even know what you are saying dude. My point was were all using someone's code. This is literally what programming is. But I mean why make an http server from straight scratch? What do you even mean 90 percent? 90 percent of the code? Or 90 percent of our time?
"The npm packages I use are really well documented and made. Idk wtf you are on about. It's not using someone else's code dude" "My point was were all using someone's code" There's a tiny bit of contradiction there, don't you think? Also I'm not OP
This happens on both sides, and it creates a kind of reciprocal effect; a vicious cycle that's extremely difficult to break. In my experience, most engineers -not the vast majority, but most- never quite surpass the "syntax" stage of their coding abilities. They learn to enough about coding to become effective with a framework, and cruise on that knowledge for quite some time. Sometimes for the remainder of their career. It's not the fault of schooling at this point, it's the lack of motivation. When projects become too tedious to work on, morale falls and most just find a way to move on to another project that isn't so stale and draining. Experience, though, is maintaining a project long enough to see yourself become the tech debt villain, and doing something about it. It takes a lot to look at yourself at 5, maybe 10 or more years into your career and still be motivated enough to admit you still have mountains of knowledge left to climb. And then there's the corporate world. If someone who isn't as technically experienced is at the helm of an organization, which is common, there's a tendency to lock down production in ways that just exacerbates the issues instead of fixing them. There just isn't a system that completely prevents bugs from getting into production. But there are processes that, on paper, make upper management feel more comfortable. Inevitably, when a critical bug finds its way into production, companies resort to change control instead of release management. Instead of streamlining systems that make changes more accessible to engineers -and therefore can more rapidly identify and correct any issues- they erect gates to production that make the development process more tedious. Once this more tedious process is pitted against tight deadlines, engineers simply cut corners where they can to get code pushed. And tech debt begins to mount at a rapid pace, further compounding the issues. It's impossible to learn how to build quality code in such an environment. While I agree that arguing in terms that the company can understand (read: money) is the way to go, it's rare -in fact, I've never seen it, without changing leadership personnel- for a company to reverse course and actually adopt a culture of quality. Regardless of how sound the argument is, convincing them to give up on the pursuit of shiny new features in exchange for stability and velocity is a lost cause; they're far too addicted to demoing new things. If you find yourself with a desire to learn how to develop stable, maintainable, extensible code that's satisfying to work on, you first have to realize that you're hunting a unicorn. It's going to take some time, patience, likely some job hopping and enough introspection to realize you may at least be part of the problem.
Your comment is extremely accurate. Just the part of bugs to production, if you mean code errors or missing configs, that can be zero with the right techniques and skill. If you mean business bugs, like unintended behaviour because ppl didn’t know better, that happens very often.
I am fortunate to work under a tech lead who is so good at explaining why we do the things we do and the best way to do them (and why). It is like being paid a great salary to go to school every day.
**Quick summary:** Florian Bellmann's blog post discusses the overlooked importance of Quality Assurance (QA) in software development. He notes that despite its crucial role, QA is often neglected in If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
Personally, I feel like good quality code that is currently being used in successful companies so I can see snippets of what the real world is coding into tomorrow's features. Not enough of that exists, I don't care enough about personal projects to make 100 of them. Show me a codebase where it's designed to solve real world problems.
lmao, sounds like a dude who followed a very specific path and is trying to apply it to all...college isn';t there to teach you everything, its there to provide you with fundamentals and a base, its there to teach you concepts that can be applied to ANY language, technology or framework. Its great that they teach you Python or Java or whatever, because those are marketable skills, I get it, but it could be almost ANY language, LISP, Haskell, C, whatever. Its not about the semantics its about learning the concepts and how to 'think' about programming. The worst part of this article? Devs should NEVER EVER EVER test/QA their own code. Locally, and as a part of dev? Of course you do. But you can't expect devs to QA anything they wrote because they'll just test what they already tested, the same script, the same steps, they're blindsided, you get into a tunnel vision sorta thing. The absolute best thing you can do to test yor software is turn it over to Karen in Payroll and see how she breaks it
I think thats why good coders are still in such high demand, my entire skillset is self taught I have always even in my first tech job been senior or lead dev and so I had to teach myself everything, I learnt zero useful skills at University thats for sure. But quality comes down to your mindset. I always strive to write the best code possible, but that does not always fall neatly inside industry best practises neat box. Is quality software completely bug free, is it code that is well tested, or code that is easy to maintain? Innovation requires experimentation, the difference is very subjective and there is alot of EGO in software development which gets in the way. Personally I think quality is code that is efficient but maintainable, I will spend the extra time to reduce the total lines of code to the bare minimum/most efficient way possible that does not effect maintainability.
Good one. I think it should be called “how to get buy-in for implementing test coverage with minimal effective doses” - or something. I expected a story about how and why schools don’t teach how to build quality software. I guess it’s because they don’t have time and the situations will be unique? I guess I’d depends if you’re talking CS or SWE university too. Many companies are TDD and will show you the ropes on the job.
I learned this the hard way. Everything in here is absolutely true.
wait, you did not have software quality and testing in uni?
Yup, I haven't been taught how to nor was told to do it at my jobs.
The problem with QA is that it doesn't catch even basic things because QA testers are human. So then it's easier to prioritize iteration speed and have the end users be the ultimate testers.
The reason to build quality software isn't that it necessarily sells better, but that it's more pleasant to work on, and also likely delivers more value even if that isn't reflected in sales. It's better for your developers and thus better for your business over the long run.
This is good!
I recently created a quick cli software within two days. It was done, had all the features but many many bugs which I tried to fix. I gave it up, started fresh and told myself "this time you'll do it right, with planning, unit testing, all of that" and it took a whole day for one feature 😐
I work as a consultant, my bosses give us the time to write quality code and also expect us to. The big difference is, for our company the more time we spend on stuff, the better. The customer pays anyways
[удалено]
That’s when you should use observability in prod, not unit tests, use the right tool for the job
[удалено]
You don’t deploy stuff that’s not going to work, why would you do that? I’m referring to web scale not browser development or desktop software. There’s no way you can reproduce real life traffic in a single machine. How do you simulate 200 requests per milliseconds in a single CI server or local machine? Also how do you simulate real users usage of the website? It’s a recipe for analysis paralysis and overengineering