I've seen many discussions around this topic lately, but I'm particularly curious to understand why most people think that software/code quality is something secondary and could be addressed late in the process, for instance with peer review.<p>Why isn't the idea that software quality starts way before you write any line of code the predominant mindset amongst engineers / the industry?<p>I have the feeling that most companies don't hold discussions about what software quality means and how it should be measured.<p>To which extent do you agree or disagree with this feeling?
Software development is, apart from a few rare outposts like GOV.UK, conducted in the private sector for a profit.<p>That means that the <i>number one consideration</i> for the software is profitability. For internal-only software, this means that cost is the prime consideration.<p>In support of that, often software startups are trying to capture a winner-takes-all market, so <i>time-to-market</i> is critical.<p>Thirdly, consumer protection law is weak in the US, and product liability is almost nonexistant for software everywhere. The <i>cost</i> of failure is very low even if you leak all your customers' data or your product ceases to work after 18 months because you've "pivoted".<p>Fourthly, a lot of software is ""free"" or ad-funded. This further weakens the cost of failure.<p>There are techniques for delivering extremely high quality software. Few sectors of the industry care about them because it's not required and is unprofitable, but the aerospace people can usually get it right and the security people can usually get it right (when dealing with security products, not general purpose junk like Flash).<p>The automotive industry is kind of on a boundary. The Toyota "unintended acceleration" bug revealed some tremendously poor quality software. This is one of the main worries about self-driving cars: how minimal is the quality assurance going to be?
To most businesses, the core objective is creating a profitable business, and most other objectives, including engineering, marketing, support, and yes, in many companies even things like customer and employee satisfaction, are secondary to that, and only really prioritized to the extent that improving those areas also improves the bottom line (I would in fact argue that this is true of almost all companies, and that the difference in whether they prioritize customer and employee satisfaction or not, is mostly a matter of whether they look at the impact on the bottom line in a short-sighted manner, or in a more long-term way).<p>So in regards to your question, it would seem that the market reality is that a lot of the time, it is better for a company to have a quickly-cobbled-together piece of software that mostly does what the customers want (and maybe get to the market first) even if it is low-quality, than it is to have a piece of high-quality software that does less, or is finished later, but is maintainable, and potentially scalable in the future (which you'll never get to enjoy because the worse-is-better people already conquered the market).
Companies do care about code quality, but it's not the same kind of quality. This is the purpose of QA. Every company that has a QA team cares about quality at least enough to hire a full-time person responsible for it.<p>When developers talk about "quality," they mean tech debt. Addressing tech debt is problematic for businesses because it's something that never ends. You allocate one month for tech debt and the devs will ask for two. Allocate two and they will ask for three. There is no agreed-upon standard at which devs will stop and say, "Now our code is clean."<p>Add to this the fact that there are many developers who just always seem to have an agenda about the code they're working on. They never work a project except they're dying to add some pattern or change some aspect of the code, even if it's something that they used to favor a year ago.
Clients don't care about quality, they care about features, so management doesn't care about delivering quality, they care about delivering features, so engineers aren't allocated enough time to care about quality, only features. And then it's still the engineers fault when everything explodes or takes 10x longer than it should to rework or expand a feature later.<p>Basically it comes down to management that is willing and able to tell a client no, or convince the client to budget to do things right, and not management like my current company, which has in the past threatened to disallow even unit test writing and code review as slowing the process down too much.<p>"Code quality is time and money you're saving your future self" is an argument that only makes sense to people who write code, apparently, until you actually lose a client to avoidable problems.
In Peopleware, Tom DeMarco thinks it's because a business's customers will tolerate lower quality software, so there are diminishing marginal returns to revenue as investment in software quality continues. He predicts that while this management style works wonderfully for the bottom line in the short run, it causes long-term ailments such as team dissatisfaction, overly complex architectures, and other issues that may be more expensive overall.<p>Quality and security become increasingly important as we depend even more on software systems for essential functions such as cars, power grid management, agriculture, etc. Unfortunately, this situation is all too similar to how many opt for the emergency room over preventative care.<p>We should also consider that many businesses wouldn't exist if not for lax quality requirements for software products. How many product V1s are chock full of bugs and exploits, and to what extent is that okay? What about open source? As usual, it's pretty complicated.
Because of the fact that software is seen as a cost center rather than as a means of production. If you were to factor quality in right at the start most projects would never be approved and so we try to 'fix' the problem at two minutes to twelve.<p>This is also a large factor in why software projects tend to overrun both in terms of time and budget (the other large factor is bad project management).
Code Quality (CQ) is an ideal.<p>Your feeling about the magnitude of the issue (most companies) is wrong. Programmers discuss CQ principles among themselves. However, the discussion becomes more challenging with management.<p>Management is responsible for accomplishing business objectives.
Development and testing timeframes are at odds with business objectives. Adopting CQ delays product. If you're going to delay product, but the product will be beautifully efficient, idiomatic, elegant and possibly a little faster than the first pre-CQ version, you're not going to win an argument in an organizational context where delivery timelines matter.<p>Time and effort are not a programmer's friend in a task-driven organizational setting. Fortunately, real-time linters tell programmers not only about material errors but present stylistic warnings (such as Python pep8 linters). Further, static analysis tools such as Quantified Code [1] conduct an in-depth analysis of code and suggest stylistic improvements. I suspect that this is an area where machine learning will advance Code Quality further. Maybe, just as there are language servers, there will be code quality servers.<p>It is worth noting that the QuantifiedCode entity shuttered in the Summer of 2017. It's not clear why the company closed-- did they fail to monetize automated code review? Were they acquired?<p>In conclusion, the more you can automate code quality-related improvements, the more likely you can promote your Code Quality ideals.<p>[1] <a href="https://github.com/quantifiedcode/quantifiedcode" rel="nofollow">https://github.com/quantifiedcode/quantifiedcode</a>
Minimum Viable Product<p>In fact these days, people kinda know what they want, but really only understand what they want when they have something in front of them. I'd go so far as to suggest you can over-engineer a solution too easily and then spend a lot of time refactoring it. YMMV
A thought: The slightest design flaw or manufacturing flaw in a microprocessor or memory chip can reduce its value to zero. Generally, flaws in software are easier to correct and don't have the same catastrophic effect on value.
I working in consulting, and in a lot of cases while we're well intentioned in delivering quality software, we're forced to fight against clients in time, budget, scope creep etc.<p>Sadly, things sometimes get rushed out the door and it's not until some time has passed that they realise the enormous tech debt they've incurred.
How do you define software quality? Just off the top of my head, I can think of:<p>* Defect rate (does it do what it's <i>meant</i> to do?)<p>* Does it do what the <i>user</i> wants? (not always the same as the above...)<p>* Is it pleasant and efficient to use (<i>definitely</i> not the same as either of the above).<p>* Is it developed in a way the management are comfortable with? (which often seems to lean towards sufficiently "under control", replaceable developers).<p>How do you balance these? The answer will be quite different depending on whether you're landing on Mars or writing a free-to-play game.
Feature creep and timelines are in my opinion the root cause of lower quality software. Most engineers sit down planning to develop clean efficient code but that generally takes more time than they are allocated. As the deadline draws closer new features and edge cases are often added in by either management or the end user.<p>Often these new features were not accounted for in the original design and in order to fit them into the system in a nice and clean manner, a large rewrite of certain modules and/or database tables is required. Due to time constraints and developer fatigue this is not possible and the mindset of "Just get it done" sinks in. This is no one's fault just a harsh reality of writing software where timelines and profits are a factor.<p>No one wants to be the guy that hard coded several edge cases into an otherwise clean module but it happens and it happens often as "Just get it done" takes hold. I think a good developer just accepts this, and makes sure to do a good job commenting their code. This especially happens during customer acceptance testing. Customer brings up a feature that they never mentioned before, they want it now. Management and/or your bank account says just give it to them. You hard code it in.<p>The circle of life
You don't make money building good or bad software.
You make money with mainteinance contracts.<p>That's what my CS 101 professor told us our fist day at the university.
Heresy! you might think.
But it is true.<p>Making software is a one-off cost for the customer.
Maintenance is recurring income for you.<p>Custom software is Capex (Capital expenditure: investment).
Mainteinance is Opex (operational, aka expenses).
All Capex you spend will be in your books for several years (usually 3-5).
Opex is fort the year only.<p>A lot of customers will happily like to pay high mainteinance fees if you can convert those fees to development of new features (in case there is little or no debugging/improvement to do).
"If you don't ship it you can't sell it."<p>Now tell that to any sales team and they'll tell you to hold their beer. The problem is, now they've sold your vaporware and you _reallly_ need to ship it, now. Like, yesterday.
They must believe that the consequences for making it an afterthought are not severe. Depending on what they are building they might be right or wrong about that.<p>I find that in bigger teams with more complex projects that are sold to the customers it’s not usually an afterthought, they take quality seriously usually, at least relatively. I can understand why it’s an afterthought for a small startup trying to see if they can even get customers but they have to be careful too, if they do get traction then quality should be taken very seriously. I can also understand why it’s an afterthought for some internal tooling, the consequences aren’t severe.<p>I run a cloud based automated test reporting app called Tesults (<a href="https://www.tesults.com" rel="nofollow">https://www.tesults.com</a>) and I’ve worked as a software development engineer in test at large tech and game companies. Based on my experience reporting is definitely an afterthought and this makes testing in general an afterthought sometimes. You need a way to keep on top of failing tests and have some measure of the problems that are being discovered. Especially when it comes to the modern agile style way of working where constant check-ins are made.<p>Another issue is that a lot of testing now (particularly for performance and automation in general) requires testers to be engineers and in some organizations this still isn’t understood. The manual testers are still required of course for UI/UX testing but there is definitely a shift in this area and in games at least it’s taken a long time to understand that.
Unfortunately most of the business people are in a hurry to release a new feature or version.<p>There is a misconception that code quality comes in a price of developing time but in my experience I have released much faster the final product when I use unit testing, incremental releases, use code reviews and other techniques that help maintain the code quality high.<p>By not using these techniques you get faster initial release but a much slower final, bug free, release.
Human nature.<p>Quality in general has always been an afterthought by many if not most people and companies. Always will be.<p>Some people are just not quality people. But when they find their way into important corporate positions their "leadership" effectively puts a major obstacle in front of any inherently higher-quality operators or teams underneath, restricting the flow of true available quality towards the clients, customers, and shareholders that could otherwise benefit.<p>Probably why I named my first company Quality, just like so many other companies in so many fields of operation, because it's not an afterthought to me.<p>Combined, all us "Quality" oriented companies who try to choose this as a differentiator still make up a small minority and are always under continuous pressure to compromise this most elusive feature, sometimes necessary to compete or even survive in situations where higher quality is not fully valued. More often there is downward pressure when lower quality becomes overvalued, as we see this trend growing in the 21st century.<p>It's tough for so many people to tell the difference between low and high quality anyway, especially for those where it's not even an afterthought.
Businesses* don't care about quality until it's too late.<p>They pay lip service to it, sure, but when it comes down to it most don't care enough until it actually starts to affect the bottom line. And longer, more expensive development processes are already affecting the bottom line, so come on, get it out the door!<p>Plus a lot of engineers see quality considerations as a drag. If they can find a home in a company that doesn't want all this "extra" stuff done then, well, this is what you get.<p>There are notable counter-examples in companies - Big Blue has a huge focus on quality, and their teams put a lot of effort into it (note I am saying nothing about usability here...) which is possible because a lot of stuff there moves slowly anyway. It's also because IBM are very, very good at measuring their cashflows and costs and have figured out just how much lack of quality can impact their bottom line.<p>There are also many individual engineers in smaller companies who put quality up front, and try their damnedest to push it through even where the business may not really care.<p>( * mostly SMEs are terrible for this, IMHO, though one or two large corporates I've worked with haven't been that great either)
Many software companies fail outright. Other enduring bad software delivery outfits enjoy specific types of subsidies or captive pricing powers until they fail. Those are different cases.<p>Outright unsubsidized failures that never deliver any product to customers are mostly functions of communicative challenges. The opacity of costing for simple speed/space or protocol adherence engineering decisions is easy to underestimate. Business actors will nod and agree to anything that sounds good and give wrong signals. Others wave hands frantically around every buzzword and easy windfall demanding features. Many purchase agents subject to hype have no idea what they are buying and fetishize wasted software LOE. Training is routinely shortchanged for industries with high turnover.<p>Accept failure and then low quality as the norm. Then seek team members, suppliers, channel partners and customers around new or rekindled software with needs to focus intensively for 2 months and then 24 months. Most enduring software requires stakeholders more than customers. Leave other endeavors up to researchers and understand what capital resources amplify or do not amplify.
If software is created within a profit oriented organisation, then there is a rush to get stuff out the door. Quality is seen as an expensive intangible. Managers are focused on time to market - the shorter the better and costs - the lower the better.<p>When software is created without a profit motive, then it is to coolness of the idea that motivates the creators. Focusing on quality would only slow down the "creative" process.
Management incentives and profitability aren’t aligned to software quality...until they are (see: Equifax), and <i>perceieved</i> software quality is given priority over actual software quality. Also, if your product is a monopoly or relatively monopolistic, then software quality literally doesn’t matter because customers don’t have a choice...until they do (the very definition of disruption)
Design by committee vs design by vision. Takes guts to have strong opionions and stick to them.<p>At almost every company, the primary background motivation is not getting fired. Virtually no one even aspires to great work let alone takes the risk to have a vision.<p>This is pretty rational. There's just no incentive to risk your neck pushing for quality when you'll just end up working a lot harder for little reward.
Software quality is one of my main professional areas of interest.<p>I agree with the general sentiment. Things have improved in recent years though, in part on account of movements like software craftsmanship, habits like clean code and also because software is becoming more easily and more rapidly testable due to better testing frameworks.<p>Testing frameworks are only one part of the equation. As you stated correctly software quality starts at the beginning i.e. with the requirements or rather even earlier when defining your values and expectations for your project and the software you create for it. There's no shortage of tools for this aspect of software quality either. Those are less rigorous though and emphasise communication rather than true / false (test succeeded / failed) outcomes. Communication is a vital component of good software quality but it has a way of becoming an end in itself rather than a means, e.g. in the form of pointless, cargo cult meetings.<p>Furthermore, in order to accurately measure software development outcomes it is essential to have clearly verifiable acceptance criteria. Defining those can be time-consuming.<p>Simply put, software quality requires investment, both in terms of time and money. Not investing in software quality means taking on massive technical debt. It's unfortunately still a common practice because often a lack in quality will only come back to bite you after some time. It's relatively easy to temporarily cover up and paper over quality deficiencies by implementing workarounds or simply by putting in extra hours. Those temporary measures aren't sustainable in the long run though. They just lead to more technical and organisational debt. Ultimately that debt can become unmanageable.<p>Much like in the boiling frog parable that increase in debt happens very gradually so it's often not perceived as a problem until it's (almost) too late.
If you think about it, software quality is not something that is ever visible or measurable from the outside.<p>Theoretically, you could write software by just having an incredibly long list of test cases and a random string generator.<p>The quality of that code would probably be terrible, but it would still work as long as your test cases are restrictive enough.
The problem is, money loss through poor software quality is (and maybe can) not be calculated in a way that, for example time (for development) can be measured. Often the arguments for increasing software quality, for example through refactoring parts of a codebase, are therefor not fact-based, but mostly vague. This is often not enough to encourage the decision-makers to invest in good software quality.<p>Apart from that some people might deliberately choose to not care about good software quality. But in my opinion this is often a sign of missing/poor education/experience.
Adding to other answers, I have noticed this behavior very common in startup scene, where many of them are not actually building a brand for lifetime, but to quickly add pleaothera of features so that they can be sold at a good price.
The difference in money, and perhaps more importantly, time, between great software and good-enough software is large enough that most companies will require good-enough.<p>There are two big trade-offs in time alone: missing the chance to be first to market (mongo vs rethink comes to mind, albeit not quite accurate), and the need to get feedback early and often enough to pivot if the idea isn't quite right.<p>Then the layers of lava come- not enough time to rewrite everything now that the domain is better understood, the prototype becomes the foundation, and cruft builds up.
If you embrace the idea that software development is a process of figuring out what to do - there is just no place for quality at the start, only for throwaway prototypes. And you have to avoid any rigidity at that stage, as it only slows the development down. Quality should be introduced later, once you know for sure you would need a production quality implementation of something. Maybe check out whatever Fred Brooks wrote about this.
I wrote an article detailing why companies acquire technical debt/bad software. It's typically sacrificing quality for short term gains. <a href="https://medium.freecodecamp.org/what-is-technical-debt-and-why-do-most-startups-have-it-9a54458daabf" rel="nofollow">https://medium.freecodecamp.org/what-is-technical-debt-and-w...</a>
Any organization that has a "normal" modern development process (Code reviews, Reasonable test suite, continuous builds, static analysis etc) has a decent focus on quality. That doesn't mean quality has the focus it needs within the organization but at least its then not secondary or a focus for late in the process.
>I have the feeling that most companies don't hold discussions about what software quality means and how it should be measured.<p>I have instead the feeling that the matter is endlessly talked about in meetings but noone actually puts in practice the "good intentions" discussed (for the one or the other reason).
My feeling is that this type of secondary thought will be seen more often in places where management has less experience with programming. Also, it will happen more in places with less process in place.<p>If you cannot manage the complexity of the software developed, you increase the risk of creating lower quality software.
When it comes to controlling costs, reducing quality is one of the few levers we have. When it comes to developing software the trade-off we're making is usually not whether we make low or high-quality software, but whether we make low quality or no software.
In my experience, it seems like people who don't have much hands on experience are leading the show, and don't realize the value in well designed, clean code in minimizing bugs and and decreasing development and maintenance cost in the future.
A lot of views here are based around a capitalistic rational. Though true, I think there are many companies out there that value certain types of cultures, and some of those cultures include good quality software design.<p>But this is certainly not the majority.
Did you ever hear: "I love to code", "Writing code is so much fun" ?<p>Software is not made by grownups. And for the most part the development is not managed by grownups. The problem is that so many can get away with childish behaviour.
Here are just some causes (IMHO) of poor quality software:<p>1. Creative and intelligent people are forced into an industrialized process of distributed micromanagement (Scrum) which stifles their ability to create a truly wonderful product and instead leaves them feeling lost and producing their worst work.<p>2. Idiots are running the show.<p>3. Quality is seen by the above-mentioned idiots as a threat to the deadline, whereas the reality is that low quality spreads like cancer and kills projects before they can deliver unless a series of miracles occur, in which case they deliver over time, over budget, descoped, and full of bugs.<p>4. Implementing non-functional requirements (i.e. the environment in which features exist) doesn’t visibly demonstrate progress to stakeholders, so this activity is deprioritised in favour of building features so there will be something to demo at the next showcase and the project manager can keep his job. At some point, as developers try to implement non-functional requirements, they’re faced with features that haven’t implemented the non-functional parts and features that have to be rebuilt after the non-functional requirements are implemented. After some time, the developers “come clean” to the project manager about incomplete features when, in fact, those features couldn’t be completed at the time because the environment in which they are supposed to exist barely existed itself.