140

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.

closed as primarily opinion-based by gnat, Doc Brown, amon, GlenH7, Greg Burghardt Sep 22 '17 at 20:02

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

263
  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.
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – yannis Sep 22 '17 at 8:50
  • Where can I get those insights systematically of I don't have any guidance? – Ooker Sep 22 '17 at 17:47
  • 4
    Don't just understand what the best practice is, but what the tangible benefits of a best practice. The allows you to connect the best practice with appropriateness and also ensures effectiveness in applying the practice to have the best effect. If you just recite that a best practice accomplishes "separation of concerns", then you probably can't be sure you are slicing the right way to reap the benefits of the practice. – AaronLS Sep 22 '17 at 18:45
51

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.

  • 2
    @nocomprende: no entiendo... Do you mean that the common is more common, and the extraordinary is, unfortunately, extraordinary? Or that the common is not extraordinarily good? Well, yes. – Peter A. Schneider Sep 21 '17 at 17:41
  • 3
    "What you learn in university is actually not common in much of the field" - That seems to be the key... – Brian Knoblauch Sep 21 '17 at 20:16
  • 1
    I just meant that the software field has people with the full range of human ability, the full range of expertise, companies have the full range of preparedness, the full range of kinds of problems, and so on, like the rest of the world. Software is not any different in these ways than other fields. The problem could have been posed in any SE site. – user251748 Sep 21 '17 at 20:33
  • 1
    "safety relevant software depends on well-vetted tools (we are currently using a validated C++ compiler from the 1990s)" sounds pretty cutting edge to me! – Hovercouch Sep 21 '17 at 21:26
  • 1
    @PeterA.Schneider it was a silly joke about how cutting-edge it is to actually vet your tools. ;) – Hovercouch Sep 22 '17 at 19:36
16

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.

  • 6
    Nice to address the tech stack the question mentioned – jasonoriordan Sep 21 '17 at 15:46
  • 5
    Who wants to look through 20 classes nesting and calling each other just to figure out what happens when you check or uncheck a check box? Only crazy people, or people who think college professors are gods. – developerwjk Sep 21 '17 at 21:41
  • 1
    Actually, when WebForm was created, industry standard practices were different (or nonexistent), and already existing applications never receive a refactoring when "the new cool way to do things" starts being adopted. That's why you see a lot of WebForm code cluttered with mess. Programming principles are abstarcted away from the tech stack you're using, so they can be applied even in WebForms, Cobol, Assembly, whatever. – BgrWorker Sep 22 '17 at 6:52
  • 1
    Yeah, it's true. How many MB was your ViewState? Oddly, I think Server-side controls tended to encourage business logic into the UI. Yet the programmer was much at fault for readily going along with the asp.net cargo-cult programming crap. Thus: so many events that business objects couldn't get to a correct state. Bus. objects couldn't call each other due to UI coupling. Then: oh, look Mo! We can work "disconnected!" nyuck, nyuck, nyuck. Real data volume brought your app to a grinding halt as asp.net classes pretended to be a database engine. But we were saving connections from wearing out! – radarbob Sep 22 '17 at 7:39
  • 1
    All of this rant is true... heart wrenchingly true. I have seen so much of what is described in this post concerning WebForms applications it makes me feel like these applications are little better than some PHP scripts thrown together by a high schooler strung out on energy drinks - and it was considered enterprise software! – Greg Burghardt Sep 22 '17 at 20:08
12

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...

  • 2
    So, only hire well-qualified, fully trained and enthusiastic people to do... well, anything. Why are we not doing this? It begs the question: how should the not well-qualified, not well-trained and unenthusiastic people live? Charles Dickens reported the answer to that one: not very well if at all. – user251748 Sep 21 '17 at 16:05
  • @nocomprende, you are projecting your opinion, I did not imply what you wrote in any way. I am explaining reasons for the fact the OP noticed. – AnoE Sep 21 '17 at 17:17
  • I just keep thinking about Kurt Vonnegut's question from God Bless You Mister Rosewater: "What in hell are people for?" – user251748 Sep 21 '17 at 20:31
  • 2
    @nocomprende, if I talk about a "non-trained person" I am not saying that people are stupid, I am saying that for whatever reason a person did a job who was not well-trained for that job. The fault could well be with his manager for giving him the wrong job; or with circumstance (i.e. a co-worker getting ill), or whatever myriad reasons you could imagine. It has nothing whatever to do with suggesting that we only should hire great people. If I have to fix the plumbing in my house, you can be pretty sure that I will make a mess, although I am great at whatever else I might do. – AnoE Sep 22 '17 at 8:39
  • 1
    There is an old idea from Anthropology, that slave societies like the Ancient Egyptians got far less out of people than societies that help people 'flourish'. This is why Capitalism was better than medieval culture. Ideally, everyone would be able to make it to flourishing, and then we would get the full benefit of each person, and each person would get the full benefit of society. Capitalism is not good enough to ensure this, so we need something more. That there are people doing less than optimal work is the proof, because if Capitalism was perfect, this would not occur. – user251748 Sep 22 '17 at 15:39
11

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....

  • 16
    Nothing to do with Spain. It's the Peter principle—people get promoted out of the positions where do well until they reach position where they don't, and get stuck there, because there is nothing to promote them for. – Jan Hudec Sep 21 '17 at 8:38
  • 3
    There is also the fact that software industry is still growing, so people with relatively little experience are more numerous. And that many companies don't have any experienced people at all, because they are new and too cheap to hire a veteran, thinking a bunch of greenhorns fresh from the college will do—they won't. – Jan Hudec Sep 21 '17 at 8:40
  • 1
    @JanHudec I dunno man, I feel like I'd much rather have a youngling fresh from college than one of those 20+ year experience people the original poster talks about – Mikey Mouse Sep 21 '17 at 9:00
  • 9
    @MikeyMouse, true, there are many people who don't have 20 years of experience, but rather 20 times 1 year of experience. And they spell really big trouble. – Jan Hudec Sep 21 '17 at 10:03
  • ".. peter principle.."; particularly in a government agency where it is a more conscious phenomenon. I call it their Management Inbreeding Program. While often there is an equilibrium of good/bad coders the horror is when the MIP re-enforces incompetence. Years later when those certain jr. programmers are now division chiefs, who in turn will not promote anyone better than they, good people and ideas leave or are forced out. The shop has become a basket case of incompetence; stuck in the "remnant background radiation mindset" of programming on mainframes in a culture of go along to get along. – radarbob Sep 21 '17 at 23:31
7

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.

  • 19
    I really dislike this myth that good code is self-explanatory and comments are obsolete. At best good code will tell you exactly what is happening. However, it gives no indication as to why it's doing something or even if it's correct. Comment your code so that its future maintainer doesn't have to guess why you're fobricating foo but not bar. – cpburnz Sep 21 '17 at 13:16
  • 13
    I disagree with your first paragraph. Documenting your code (for example with comments) is at least as important as when you were in college. The difference is that no professional will comment what a line is doing - they will document WHY. What is happening can be read from the source code. Why is often the result of several minutes to hours of thinking. – Araho Sep 21 '17 at 14:23
  • 1
    There are very few reasons to write why the code is doing something, and most of the times it could be explained with a better method name. Let's face it, most of the code we all normally write is simple enough to not deserve comments. – BgrWorker Sep 22 '17 at 6:57
  • 1
    How does that go again? Code is written once and read many, many times over. Write comments and you'll be saving time in the long run. @BgrWorker Depends on the person, I guess. I regularly write algorithms and I think they deserve comments (most recent being a symbolic math parser... definitely needs comments) – person27 Sep 22 '17 at 7:14
  • 1
    I think unit tests are far more valuable than comments. Too often I have seen situations where the code was updated and the comments no longer apply. In this case the out of date comments make it harder to figure out what's going on. Unit tests document the intent of the original programmer, and if your CI system runs unit tests on check-in then you are obliged to maintain them. – bikeman868 Sep 22 '17 at 7:38
2

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.

  • Failure is usually not an option either. – user251748 Sep 22 '17 at 17:32
1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.