Are bad programming practices typical within the software industry?

Question

I just started my first job as a software developer over a month ago. Everything I have learned about OOP, SOLID, DRY, YAGNI, design patterns, SRP, etc. can be thrown out the window.

They use C# .NET Webforms and do almost everything within the Code Behind with very few external Classes, definitely not called objects. They do use custom controls and reuse them. About the only objects used is by Entity Framework. They reuse the Code Behinds for each client. They have methods which are 400 lines long doing all types of stuff. For new clients they take the aspx and the aspx.cs and strip out the client code and start adding the new client-specific code.

Their first excuse would be it adds additional maintenance, and more code is more maintenance. It is a small shop of three developers including myself. One developer has over 30 years experience and the other has 20+ years experience. One used to be a game developer and the other has always worked in C and C++.

How common is this within the software industry? How can I ensure that I stay on top of OOP and the related principles? I practice in my spare time, and I feel like I really need to work under a more experienced developer to get better at OOP.

Answer 1

1. The principles that you cited in your question are just that... principles. They are not mandates, laws or orders.
2. While the people who came up with these principles are very smart, they are not absolute authorities. They are just people offering their insights and guidance.
3. There is no "correct" way to program. This is evidenced by the fact that the "accepted" way we do it has changed, and continues to change, radically over time.
4. Shipping a product can often take precedence over doing it the "right" way. This is such a prevalent practice that it has a name: Technical Debt.

5. Some software architectures in common use are not ideal. Best practices are evolving away from large, monolithic applications towards loosely-coupled collections of modules.

6. Context is important. Many architectural principles only prove their worth when you're working with large programs or specific domains. For example, inheritance is mostly useful for UI hierarchies and other structures that benefit from deeply-nested, tightly-coupled arrangements.

So how do you follow a "right" path, a principled path, so that you can emerge from the wilderness?

1. Study appropriateness, rather than correctness. The "right" way to do anything in software development is the one that most effectively meets your specific requirements.
2. Study tradeoffs. Everything in software development is a tradeoff. Do you want more speed or less memory usage? Do you want a very expressive programming language with few practitioners, or a less expressive language that many developers know?

3. Study timelessness. Some principles have stood the test of time and will always be relevant. Type systems are universal. First-class functions are universal. Data structures are universal.

4. Learn pragmatism. Being practical is important. Mathematical purity, crystal-cathedral architectures and ivory-tower principles are useless if you cannot ship.

5. Be a craftsman, not a zealot. The very best software developers are the ones who know the rules, and then know how to break them when it makes sense to do so. They're the ones who still know how solve problems and think for themselves. They use principles to inform and guide their choices, not dictate them.
6. Write code. Lots of it. Software design principles are premature optimizations until you've written a lot of code and developed an instinct for how to apply them correctly.

Answer 2

It is not uncommon. One thing to realize is that the software industry is incredibly diverse. Some companies are cutting edge. Leading universities and innovative software companies (even some labs in the big ones!) as well as blessed persons or groups like the gang of four analyze the problems occuring with the common ways to do things and invent new languages, machines, tools and patterns. New companies, often spin-offs or split-offs, try to use those commercially, and sometimes have amazing success. Think Facebook or Google.

But software is used almost everywhere these days, perhaps mostly in companies which are not actually software companies. I have worked mostly in the transportation industry (automotive and railway), and there is a mixed bag of experiences. But none of them was anywhere close to the "cutting edge". Sometimes they can't be; safety relevant software depends on well-vetted tools (we are currently using a validated C++ compiler from the 1990s). Sometimes they don't have the right people. Often the software is developed by engineers in other fields who just happened to slide into software development in their company when software became more and more important. One cannot expect them to know or use software engineering principles.

Another thing to consider is what is important in an engineer in the real world. Often the task at hand is, quite literally, not rocket science. The bread-and-butter problems in non-software companies can be solved with modest software means. What makes a useful, perhaps even good software engineer is partly what makes a good general engineer: Be reliable; organize and document your work responsibly; be cooperative; make good cost and time estimates (the validity of the estimate is more important than the actual cost and time!); understand what you can and cannot do. Conspicuously missing here is "know and use state-of-the-art tools and procedures". What you describe is a company which has established a tool set and process which works for them. They will probably never produce anything sexy or extraordinary, but they meet customer demands well enough to generate a steady stream of sufficient revenue. That could be the definition of engineering ;-).

So yes: What you learn in university is actually not common in much of the field.

---

I want to add a piece of consolation, or a more upbeat note. What you learned should not be thrown out of the window. You can apply better principles in your daily work where it doesn't break things. Perhaps there will be a window of opportunity to introduce a new tool or design pattern. Chances are best when the old way of doing things is unpleasant for the colleagues, or if they run into problems with managing complexity or maintenance (the two most virulent problems addressed by innovations). Be ready to offer improvements when there is an opportunity. Be a positive influence and incrementally improve methods and tools; spread knowledge where it is appreciated.

Answer 3

They use C# .Net Webforms and do almost everything within the Code Behind with very little External Classes

There's your explanation right there. If you aren't aware, out-of-the-box Web Forms code is pretty much the polar opposite of OOP, SOLID, DRY, YAGNI, Design Patterns, SRP, etc. Even the official examples from Microsoft from a few years back would make you cringe today.

Web Forms pushes itself towards a procedural flow, with some fake "events" triggered by control clicks and the like. Devs who spent lots of time doing Web Forms also usually seem reluctant to depart from it as well, probably because they sunk so much time into learning the page life cycle and how to do dynamically rendered controls that they are loathe to throw that knowledge away now in the face of newer/better methods. An unconscious version of the sunk-cost fallacy. These devs have spent the years learning how to wrangle Web Forms, and now will not easily depart from that expertise, hence their talk about "maintenance" time.

And this is quite common in the .NET Web Forms space, btw.

Answer 4

How common is this within the software industry?

Very common. About the same commonness as having a plumber destroy your plumbing, a carpenter delivering junk, or a cheap tailor making a bad-fitting suit. I.e., it's all human.

There is a good reason why this happens: people who are not really trained (or not enthusiastic) having to implement something under pressure.

This is not a problem of those people, primarily, but usually of the structures surrounding software development in that company. For example, a company might have a bunch of interns develop their internal software; even if those interns are bright and knowledgeable, they will only be there for a few weeks or months, and ownership will switch frequently.

Or some person that is great in the domain, but not a programmer, might hack together some VBA etc. application because it seems to be quite easy at the beginning.

Or a well-made application ends up in the maintenance phase, all good developers move on, and it is then continued to be developed by few people (worst-case: one) who know little about it, who have no documentation, etc.

How can I ensure that I stay on top of OOP and the related principles? I practice in my spare time and I feel like I really need to work under a more experienced developer to get better at OOP.

There are two possible answers:

• Either: discuss this with your boss and make sure you get into clean projects. If not possible, find a new boss.
• Or: take on responsibility for this yourself. That means doing it on your own - in your spare time, or if you can, in the company, but driven by yourself (unlikely).

If the second answer sounds too cynical for you, then let me assure you that it is not. A carpenter who has a woodworking shop at home will most certainly be a better carpenter than one who does not.

For example, it is absolutely possible and a lot of fun for some people to, e.g., dig into a new language like Ruby, learn not only the syntax, but also indepth special OO aspects of that language, and really dive deep. All in your spare time, without having any connection to your work. It will just be a hobby, but being the trained professional that you are, it can be as effective (or more so) as sitting next to some lead developer and trying to follow what they are doing. This will then be strictly for your personal development and your own fun. If you do not have fun doing this, or if you find that you simply cannot achieve any understanding, then scratch that, and return to the first answer.

That lead developer who is training you has quite likely learned that stuff in exactly this way...

Answer 5

I think that in Spain is a constant because when a developer passes many years in a company he (or she) is usually promoted to more management areas like analysis and project management. As a result no peer review is done and the code is usually written by less experienced people.

The failures of these experienced people are never corrected: instead, their only focus to have the job done. As a result, more and more wrong practices are accumulated in the code.

Eventually some smart ass says that the best "solution" is to change to an emerging technology that will generate cleaner and more maintenable code, creating a new application. As if the technology by itself could do that.

Again, unexperienced programmers are put to work in that new technology, no one reviews the code and the circle is closed again.... forever and ever....

Answer 6

Some of the "best practices" that you learn in school aren't practical or cost-effective on real-world projects. One of the biggest changes I noticed was in formatting and comments. Most of my professors stressed the importance of extensively documenting your code, but in the real world, good code is often (not always!) self-explanatory, and more importantly many bosses don't want to pay for you to spend extra time writing comments.

You'll sometimes see programmers who are pressed for time using shortcuts and anti-patterns that require less boiler-plate than quality solutions.

However, one of the biggest problems I've noticed on many teams and projects is an unwillingness to learn new things. Many of the older programmers I've spoken with got their careers started in a 'Wild West' period of software engineering when qualifications started and ended with willingness to write code. They often majored in completely different fields, and jumped into programming with little or no formal education when an opportunity arose (e.g. their employer didn't have a programmer and needed someone to learn in order to build in-house software). Some of these old-school self-taught programmers never make the effort to learn modern coding practices, and continue to code in roughly whatever style they learned decades ago. When they end up in charge of new projects due to seniority, they tend to hold the projects back and harm overall code quality.

Of course the above does not apply to all older programmers, and newer-generation coders can be just as guilty. I've worked with many younger programmers who picked up a few tools and libraries fresh out of college and then stopped learning completely. They'll download an IDE or library once and never update it unless their company requires it (you can sometimes guess what year a programmer graduated based on how out-of-date his libraries are). They don't keep up with new features in their language(s) of choice, and never learn new languages. They don't learn new programming strategies, and may misuse patterns or paradigms because they don't know more appropriate alternatives (oh MVC, how heavily thou art abused). As time goes on, their workflow becomes more and more outdated, and they become more of a liability than an asset.

In summary, two of the biggest causes of messy codebases are rushed deadlines and programmers with outdated or incomplete knowledge. Unfortunately, responsibility for both issues can fall heavily on the boss or CTO, who must ensure that deadlines are realistic and that staff are up-to-date on their knowledge and skills. If the boss doesn't know anything about good programming practices, the best you can do is try to suggest changes and hope they are open to suggestions. Unfortunately, they may be inclined to trust the word of a more senior programmer who doesn't understand OOP and likes to write 10,000 line classes.

Answer 7

Some of the bad programming practices result from having to work with legacy software that first started development decades ago. If there is a huge complex piece of software, rewriting everything might not be an option. It might even be extremely difficult to understand everything that the code is actually doing. The best option might be to just copy what works while also trying to integrate better programming practices if you can do so without breaking anything.

Answer 8

I think it's important not to just tell right from wrong but to know reasons behind every right and wrong. When you know reasons you can predict consequences. Why use this or that principle not because it was described in a book, but because we know how it helps and what exactly happens should we break it. If you know what happens when then you can weigh pros and cons and make a decision. This will also help you to argue your position each time. SOLID and OOP can also reduce maintenance if used well.

SOLID if used too dogmatically leads to too many classes and methods which is not as all that good too. Don't overdo it. This is in part a big problem with our textbooks and tutorials as they often try to promote ideas without proper justification. OOP also has its cons. Many principles and paradigms contradict to each other. You don't need to be on the top, you need to make everything reasonable, justified, elegant and simple.

Also, because this is your first work, chances are these programmers are not very skilled. But then again, they are probably being trusted with not very hard tasks which can be done without as much skill and for lower salary by less skilled cheaper coders. This how economics works. Each workplace is different.

I understand how you feel. Don't panic. You will need what you know, maybe not immediately, but it will help you. Maybe on a different workplace, maybe on some occasions. You have time ahead of you to go further.