Does software quality really matter for Application Developer - *Practically*?

Question

Does software quality really matter for a Application Developer in practice?

I know this question seems like the most dumb question. But please see below why I am asking this question.

I am fond of such engineering principles, patterns and had been implementing and enjoying so far. But now I am realizing that such principles really do not matter for Application Developer but do matter is "development time", "application is working as expected" and "finished little late but that's OK".

I am really confused now days about practical importance of software quality and principles for a Application Developer. So looking for practical answer after my all time guide could not give answer for software quality impact organization and [importance of design code quality][2]

Tons of information is available talking on software quality and software engineering but practically are they being enforced in applications development?

I am asking this question as a Application Developer and not talking about OS, language or compiler development / innovations.

---

Thank you all for your response. Let me add more on why I asked this question on first place.

I too believe and think that there should be no hesitation while thinking about such principles. I believe that this is kind of art and strategy cannot be switched depending on something.

But if you see anything on this subject or say this post, notice phrase such as "depends on what". Now practical question is who gets directly benefited with such quality code, except yourself which is also your sanctification, Morals, ethics.

Lets take a very common example; a website having millions of hits. End user are happy because site looks attractive and they get placed order. Management is happy because development / enhancement was done within budget and all feature are implemented. PM is happy because somehow team delivered it in time. Tech Lead is happy because all heterogeneous sub systems are communicating as expected and infrastructure constraints are met. A team of 25 Developers are happy because all bugs are fixed and now their code is running; Of course they are confident since they used type safe language, great IDE and they will find line number of any run time errors since try catch block is everywhere to persist it.

Here, lets say, they did not follow any pattern or best practices. So the code is not reusable or logical layers are depend on data format or ... But for next development, there would new budget, new development schedule and developers get new task which might not be inline with past task.

So who gets directly benefited or has to enforce eliminating these by following some principles, may be by paying some extra cost in terms of time and budget?

Then who cares to follow these practically? Everybody knows its theoretical importance but in practice, is it "golden touch" or "nice to have" feature or "must have" requirement? If it does really matter, then as many are saying, why budget or time has been given most importance meaning quality as second importance.

Answer 1

Application is working as expected is not always the desired solution. How the internal working is happening is also a point to note rather than getting the desired output alone.

If it wasn't there wouldn't be a wing for Software Quality Assurance in companies.

Often software quality is neglected because we often tend to make short term optimizations.

Why do you think Application development has nothing to do with quality?

Answer 2

This really depends on your audience. If you're an independent developer and are selling your products directly to end-users, you really really should care about quality.

If you're working on apps that are exclusively used in-house by some corporation, you probably don't have to care about quality, as long as you can live with problems that come up and your users hating your guts.

The less competition there is the less important the quality is for the survival of the product. That doesn't take into account though that a high-quality app can be much more useful and save time and money.

Answer 3

It really depends how critical the application is. There are differences between writing medical software and a simple utility application.

I'm not really sure what you mean by quality?

The neatness of the source code?

The UI?

The reliability?

The speed?

The size?

It's all relative to who's paying you to do it, what they want, what they expect (these can be different and is very frustrating), when they need it by, etc.

Answer 4

You make quality software for three reasons:

1. To be well made it must be well designed, and well designed software is faster to write.
2. Well made software is easier to maintain, and everything gets maintained.
3. We write well made software because we care, and because we're professionals.

Answer 5

I would agree with in general, especially if you are not planning to mass market your product. For me most of the applications I work on are sold on an individual basis and therefore the look of the application is not as important as the functionality. I have found that rarely does an application win out because it looks better when it has fewer features. Also, I have clients get quite annoyed when a change is made to make something look better, but it either breaks the functionality or changes their work flow drastically, possibly making it slower or more tedious.

On the other hand, if a product looks nice or even beautiful, I think the users experience is a lot better and they will be happier while using it. I think they will like even ask for more modifications/additions because they enjoy using the application and want to use it more. I also think that sometimes beauty goes along with functionality: a lot of nice applications look nice because they have nice functionality, such as AJAX in web applications.

Lastly, if the application is a public facing application, then I think the look of the application is very important. (It's less important when you are working on internal applications.) If a application looks ugly at first glance when people click on a result from Google, they are less liekly to stay to see more and will go to the competitor that has the nice website/application.

One more thing: I generally try to make things look nice. I will take the extra time, even if it isn't the quote to make it more pleasing. I am a perfectionist and I want stuff I can show to other clients, not stuff I am ashamed of.

Answer 6

Most developers are capable of delivering software that does the work as expected and on or near on time. The real problem is maintenance. For short projects, maintenance starts after the deliverable. For large projects, its starts even before it reached v1.0. Good practices and quality developers create maintainable code.

Sure, your project works as expected. But every project I've seen so far as expected is not as needed. Always the client realizes that something some requested feature is not even close to what was needed, and the inevitable design change requests comes in. Or the project is successful and gets adopted by more teams in the customers org, and each time has a small change request to better fit their needs. Or the original requirement scale is one tenth of the current deployment usage, and the software must accommodate the larger user base.

And these are only the correctly implemented, according to requirements, projects. And we're all human and make mistakes, we misunderstand requirements and sometimes we deliver something way off what was asked.

It all boils down to the fact that software never freezes, as long as there is a sponsor to pay for the needed changes. Poorly written hacked software is impossible to change. the good practices impose a burden during development to ensure the final product is possible to change, refactor, debug and maintain.

Answer 7

Most non-developers would define a Quality application as one that meets their expectations. Overall, different stakeholders would have a different definition:

• Users - the application is fast, easy to use, and provides the features I need
• Marketers - it looks pretty and is easy to sell
• Management - it was completed on-time and meets business requirements
• Developers - it is easy to maintain in the long-term

Many developers working on small projects get stuck thinking about XYZ pattern, or pontificating over the right framework/language to use. These things matter on large enterprise apps, or large performance-critical web apps (i.e. facebook, google, etc), but are often less important when shotgunning the solution would be preferable.

In the end, the business owners/principals are the ones who determine your employment, their definition of quality is what matters most.

Answer 8

I make a living off of picking up projects that were started by developers who had no respect for the quality of their software.

True, the fact that I have a steady stream of clients means that instead of hiring someone like me to begin with they hired someone who did a sloppy job. So yes, in the sense that you can get away with it and still make a living, it doesn't matter.

But for me it's about more than just the short term. I would like to head up larger projects as my skill and experience grows and I could not do that if I didn't pay attention to the quality of my software.

Besides, it just looks prettier when you do.

Answer 9

Of course it matters.

Like you said, there's a lot of information out there to design applications the way they're supposed to be designed, and coded the way they have to be coded.

Even if you're an APplication developer like you call it, your teammates and colleagues won't want to work with you if you're sloppy. The quality of your work reflects on all your team.

You could spend your career developing without learning the principles and architecture, but don't expect to ever be recognized or to scale to higher positions. You won't ever be able to design the architecture of an application by yourself because you only will know to develop the most basic functionality/screens.

SO yeah...it matters. Go learn!

Answer 10

I didn't quite get your question. But in case you are questioning the need to always follow design principles and how those play into the quality of your project, here's my answer.

It depends on the phase of the project, the size of the team, and the time to expected completion.

Sometimes it's important to be quick and dirty. Get it working as quickly as possible. Using the best design pattern in these cases is overkill and not necessary. The developer who is able to deliver fast with a/any solution wins. The one with their head in the skies loses.

However, sometimes (often) the quick and dirty approach fails miserably. For example, if the project has or will have a large group of developers (more than 4) or multiple teams, then following solid/proven development patterns and techniques is the only way to succeed in the long run. Also, implementing new patterns often fails if there is a large amount of complex legacy code. Finally, expected time lines are crucial to stay in line with. If the customer is expecting some sort of prototype in a day, then don't spend a week putting together a full MVC framework.

Answer 11

I'm adding a second answer because this is my personal opinion and is how I try to operate, not only with software quality, but anything I get paid to do.

With everything, when somebody pays me to do something, I'm going to do it to the best of my abilities. I'm not going to take shortcuts, I'm not going to skimp out, I'm not going to cut corners. I'm going to put everything I can into it, because people notice that, they appreciate it, and they'll come back. It's my (or my company's) name on the product I'm giving them, and I don't want my name on a piece of shit. It might take a little more time and cost a little bit more than the other people, but that's ok.

I want to feel good about what I'm doing and I can't do that if I know that I cheaped out. Unfortunately not everybody operates like this. Ferrari didn't make their name cutting corners and skimping out. People will notice that you spent the time doing it right, and more often than not, if you cut corners, you'll probably have to go back and fix it anyways. Do you really want a reputation for making things that break?

There's a saying that says something like if a customer has a good experience, he'll tell 3 people, if he has a bad one, he'll tell 10. There's truth in that, and it's a lot harder to fix a bad reputation than to keep a good one. Sometimes those shadows of doubt never go away, and it hurts.

Doing things right the first time is always better than doing it ok the first time, and then fixing it the second time, coming up with bullshit excuses along the way.

Morals, ethics, blah blah blah

Answer 12

The first step is to define quality.

Ultimately, all that matters is what value the software brings to the consumer. So, as far as I'm concerned, there are only two things that make up "quality" code.

1. Direct value to the user. (external quality)
2. How easy it is to add more value to the software (including testing, verifying lack of regressions, build process, etc.) - internal quality.

A high quality code base lets you make changes quickly and easily, with high confidence that you're not breaking the world, and low cost to build/verify your changes. A low quality code base is fragile, hard to make changes in, and takes a long time to build/verify.

Everything else is just a guideline that builds towards one of those two points. Consistent and good naming increases quality because it makes it clear what the code is doing, and understanding what the code is doing makes it easier to make changes. Unit test suites increase quality because they make it easier to make changes in code with high confidence. "Good design" principles such as separation of concerns make it easy to make changes to code because changes tend to be more isolated.

So, yes, these things matter even to applications development. The internal quality factors make it easy to add more functionality to the application over a given period of time - however, this must be balanced against the features that could be implemented given the same amount of developer effort.

Answer 13

Is seems like you're saying that what really matters is, as you put it, "development time", "application is working as expected", and "finished little late but that's OK". Which is basically development time, functionality, and... development time.

And you're dead right. All that matters is that your product works as expected and gets out on time. And sometimes even working as expected is less important than just getting it out there.

But here's the catch: how do you get a product working as expected quickly? For a very small code base, the answer might be just to toss something quick and dirty together. There are cases where the raptor won't attack you for using a goto.

But the vast majority of cases you're working on something that you're going to spend at least a few man-weeks on. And quick and dirty code has a way of spiraling out of control and leaving your product a smoldering pile of segfaults, uncaught exceptions, and race conditions. It might happen on day two, or week two, or month two, but it will always be before you expect it and when it does there aren't any good options. You may make your first few deadlines with all of your functionality bug-free, but eventually your quick and dirty code will stop being quick and continue being dirty, and it will affect your development time, functionality, and... development time.

Alternatively, you can take the time to write readable, idiomatic, extensible code that makes proper usage of design patterns. At first it will seem like this is a much slower way to do things. That's because it is, but only for now. Three months down the line, your boss will tell you to make some change. Maybe it's porting your entire system from Solaris to Linux: since you've been writing good platform-independent code, you change a few function calls and it compiles without errors. Or maybe it's adding support for third-party plugins: since all your rendering was handled in the same area according to the DRY principle, you only have to add plugin support to one class. Meanwhile your quick-and-dirty competitors are considering complete rewrites for their product because their original code standards and design (or lack thereof) didn't account for portability or extensibility.

In short, software quality is how you meet deadlines and create properly-working functionality.

Answer 14

There is really never a good reason to write bad code.

• Nearly all software will spend most of its life in maintenance. Therefore, nearly all code should be maintainable.

• Building maintainable code doesn't take any more time than building unmaintainable code, once you get into the habit. But you won't get into the habit of writing maintainable code by writing unmaintainable code. Therefore, even code you mean to throw away should be maintainable.

• The same practices that lead to maintainable code also lead to testable code. If you haven't tested the code you can't honestly say it's working as expected. Therefore, even code you mean to throw away should be tested.

• Code that's written to be maintainable and testable has fewer bugs. Even well-written, testable code that hasn't been tested is much less likely to have bugs than badly-written, hard-to-test code that hasn't been tested. Therefore, even code you're not testing should be well-written.

What you need to guard against isn't time wasted making code good. It's time wasted making bad code work.

Answer 15

Application quality means a great deal to a developer and mostly only to the developer, rarely to the management.

When you pay attention to the good application architecture, design with the extensibility and maintainability in mind, you save yourself time and pain in the future when trying to debug code and fix things that at some stage just start to fall apart.

There is the term for those little hacks and quick fixes developers try to make - developer debt. If you make enough of them, at some time in the future you'll get stuck - technical bankruptcy. Meaning it is now almost impossible to add new functionality or change something without the rest falling apart. It is now cheaper and simpler just to rewrite everything from scratch. Management would never want to do that. You as a proud developer would never want to help "achieve" that situation, probably not even participate in a project with that development philosophy.

Answer 16

Code quality is defined by multiple factors.

You are basically saying that only externally visible factors, or a subset of them ("works as expected"), matter. These are certainly the most visible, but there is a general consensus in that without internal code quality factors, you won't achieve high external quality.

Analogy - Really great cars do not only rely in very hard testing of the final prototype. The design and development process itself must apply high quality techinques in order to achieve a car which is a candidate to being a great car.

Answer 17

Thank you all for your response. Let me add more on why I asked this question on first place.

I too believe and think that there should be no hesitation while thinking about such principles. I believe that this is kind of art and strategy cannot be switched depending on something.

But if you see anything on this subject or say this post, notice phrase such as "depends on what". Now practical question is who gets directly benefited with such quality code, except yourself which is also your sanctification, Morals, ethics.

Lets take a very common example; a website having millions of hits. End user are happy because site looks attractive and they get placed order. Management is happy because development / enhancement was done within budget and all feature are implemented. PM is happy because somehow team delivered it in time. Tech Lead is happy because all heterogeneous sub systems are communicating as expected and infrastructure constraints are met. A team of 25 Developers are happy because all bugs are fixed and now their code is running; Of course they are confident since they used type safe language, great IDE and they will find line number of any run time errors since try catch block is everywhere to persist it.

Here, lets say, they did not follow any pattern or best practices. So the code is not reusable or logical layers are depend on data format or ... But for next development, there would new budget, new development schedule and developers get new task which might not be inline with past task.

So who gets directly benefited or has to enforce eliminating these by following some principles, may be by paying some extra cost in terms of time and budget?

Then who cares to follow these practically? Everybody knows its theoretical importance but in practice, is it "golden touch" or "nice to have" feature or "must have" requirement? If it does really matter, then as many are saying, why budget or time has been given most importance meaning quality as second importance.

Answer 18

I try to always write good code for self satisfaction. =)