To be strict or pragmatic?

Question

I'm beginning to realize that developing software is (amongst others) a process of constantly asking yourself questions. Questions regarding quality of code, separation of concerns, minimizing dependencies, ...

But the main question is: how far can you go without ending up in a mental hospital?

I'm applying for a new job. Yesterday I was with a possible future employer who wanted to test my programming capablities. One of the exercises was: explain what this code does. I went through some code of the application (winforms in vb.net) that they develop (it's an administrative application for a hospital). This gave me the opportunity to actually see how they approach things and it was rather disappointing.

Some examples:

• I saw somewhere: Call [insert name of subroutine here] -> I was struck: isn't that something from VB6?
• They have a separate datalayer, using ado.net, but one method I had to examine returns a dataset to the calling layer. So separate datalayer or not, the application is tied to ado.net (which could also never be a problem if they never switch to another data access approach).
• That dataset is read as-is, so it still is a data-centric approach (of course, one can argue how much logic/behaviour you can put in classes like "Patient" or "LabAnalysisRequest".
• I also believe to have seen the construction of an sql query by string concatenation.
• They use stored procedures (which, to me, means: scattering of logic)
• no mention of views/controllers: it's all form driven
• The most ugly thing I saw was:

      If TestEnvironment.IsTesting then
         someVar = [some hard coded value]
      else
         someVar = [some dynamically retrieved value]
      end if
      [remainder of the function here]
  

It's all so different from what I learned in school: (persistence agnostic) domain layer, persistence layer, presentation layer, unit testing, ...

So I rephrase my question: how fundamental or dogmatic should one be? To what extent should a programmer stick to his or her principles or just write code that does the job?

Answer 1

I know that doesn't directly answer your question, but I still feel this is worth more than a comment:

When you do a job interview, you're interviewing them as much as they are interviewing you. Break the habit of seeing an interview as something you crawl to on your belly pleading for them to offer you something. They checkout you, but you checkout them as well. If they don't like you, they won't hire you. If you don't like them, don't go working there.

Yes, in the industry, with a ten year old legacy code base that's been hacked to over time by three dozen developers with different background, skill, and passion, driven by tight deadline, lack of resources, and financial constraints, the code will never look the way you (should) have learned it ought to look. You will have to make some concessions. But how many, and where you draw the line, that is totally up to you.
Of course, jobs are harder to find the less concessions you make. But they might be more enjoyable.

FWIW, I have so far (>10 years in the industry) never worked in a big company with many developers (~30 developers was the most, a dozen the norm), because it's so much more likely that you change something in a small company. As long as I make enough money to not to starve the kids, I wouldn't want to be a small cogwheel in a big company, where all I have to do is to turn in sync with the rest of the gears.
I have turned down job offers after seeing the tests they wanted me to pass. I'm a C++ developer, and there's many C++ tests out there which are so bad it makes your toenails curl in disgust, and I don't want to spend my time fighting windmills because they hired morons who can't write clean code.
I have also left jobs after a few months because their programming philosophy (short term goals, never mind next year) didn't fit with my abilities (long term code stability), despite them saying different in the interview.

Answer 2

Never write code that just does the job. However be equally willing to examine your doctrine. Just because you learned it in school, doesn't mean it's current thinking, or even valid thinking. Software design life cycle is become obsolete, due to programming having to be more reactive to the business world. Sometimes awkwardly linked software solutions are awkwardly linked because parts were replaced as time allowed.

Here's a list of issues I've compiled that will determine how well you fit into the coding lifestyle of a company.

1. How much they value setting time aside to refactor and bring their code-base up to date. How they view updating code-base will be a major determining factor in how well you fit in.
2. How often do they buy 3rd party instead of coding in-house.
3. What do they think of open-source software. Do they realize they have flexibility in altering the code. Do they view it the same way as buying 3rd party.
4. You'll be working on a certain abstraction layer. Do the team you interface with determine your interface for you? Which layer/team/side of interface has more power in decision making.
5. How much do supervisory listen to the programmers when making decisions. When a programmer throws a red-flag, does the supervisory stop and review their decision.
6. Do you consider the management experienced programmers? How do they view their experience? Is their experience valid? Are they letting outdated experience affect decision making?
7. How sticky is the code-base?
8. How often do they update their programming tools (IDE, etc.)

The answers to these questions better fit how you will value their programming lifestyle, than seeing if they match up to your dogma.

Dogma will inevitably be broken (we just don't have time to update X). However, priorities will define how much you clash with their style and decision-making.

Answer 3

I think you have to weigh this as part of the whole. I remember that one of my first jobs was a position in a group that told me they were doing object-oriented C++ - which was what I had just done several years of in school.

Their self-assessment was wrong - they were doing somewhat chunky C. It was still very functionally designed in nature and I had to go get myself a C book to teach myself printf and getf and other C mechanisms that I had never learned. The fact that no one on team even realized how C like their code was points out how off the mark this "C++ design" had fallen. My goal at the time was to be doing OO development, so this was kind off-putting.

But I'm glad, in the end, that I stuck with the team. They were a dynamic group of very smart people and I got my feet wet with plenty of hard problems, I got to work the whole lifecycle and the stuff I learned about the problem domain (PKI) has fueled my career ever since. The work that the team was doing in the functional space was amazing and I still think very fondly of that product and that work experience. Better yet - I still work with some of those people today (several companies later), they are still an inspiration, and we are still doing good work.

I don't think that perfect implementation of the best practices of a coding language is the make or break of a good work experience or a good team - the work that fuels a career is a lot more than that, and if the product has decent quality, the team has decent working conditions (like the Joel Test) and the team is full of people who are smart and get things done, then the perfection of the implementation is secondary. Take away factors like good work, good people, good working conditions - and it's not worth sticking around - whether or not the code is oddly put together.

Answer 4

how fundamental or dogmatic should one be? To what extent should a programmer stick to his or her principles or just write code that does the job?

The most important thing to remember here is what is your purpose?

In most companies, your purpose in life is not to write perfect code. Your purpose is to deliver value for the user. Writing good code is usually the best way to deliver a good product that is also easy to maintain, trouble shoot and develop.

Good code is a tool which you should apply where it gives you good ROI.

Some examples:

1. I would spend a lot of time designing and coding my APIs, especially my business tier's API. A lot of other programmers are going to use them and it will save a lot of time and problems if they are properly designed
2. I will relax the rules a bit in my presentation layer. There I will be more inclined to sacrifice code "perfectness" in favor of adding more features

Bottom line, you need to have principles but you should also be flexible enough to break those principles when they bring more harm than value.

Answer 5

In 99% percent of cases, you should stick to the « dogma » as you call it. The dogma is made by experienced persons over years of practice, and what would seem pragmatic at some point really often isn't. This is usually more relevant than the fact that you are not good enough to handle that problem properly.

However, don't follow the dogma blindly. Remember what conclusions lead people to follow that dogma. Because you'll find a tiny portion of cases where it shouldn't be followed. Anyway, those cases will be very rare and you should always discuss with some other experienced programmers before taking such a decision.

Answer 6

I worked for an e-commerce retailer for a few years. When I started there, the code for their internal applications was all written in VB for MS Access, and it was horrible to say the least. I had a team of 3 developers, and over the next few years we replaced this with proper VB.Net applications.

But since my hiring budget was extremely limited, I could only afford junior programmers. And, of course, the code they produced wasn't all that great. But it worked, and the company used these applications to make money, every day.

And then I started working with my guys. A bit of training in OOD, in database design, in MVC, and C#. And over the years, things improved. When I left after 4 years, the codebase was still not great, but it was 100 times better than when I started.

A situation like the one you describe is often the consequence of having to make do with resources that are available. We don't live in an ideal world. At the same time, this is a great opportunity to actually make a difference.

BTW: some of these applications are still in use, virtually unchanged from about 3 years ago, and they still make money.

Answer 7

I think sticking to your principles is very important. You should always strive to produce the best code possible within the constraints given. However, if you add "should never have to read or change bad code" to your list of principles, you're going to have a lot of difficulty finding work. Remember that 50% of programmers graduated in the bottom half of their class. Even on a one man team, "today you" is better qualified to solve a problem than "last month you." Being able to work with non-ideal code is just part of the job.

A lot of employers recognize that, so they code they give you to read may be representative of the worst code in their code base, rather than their best. If that's not clear from the context, you should ask. One colleague I sometimes interview with has a page of code he purposely wrote poorly just to use as an interview question.

Answer 8

Be strict when it matters. Brace style (or other coding conventions)? It doesn't matter. Use the one the shop uses. Breaking encapsulation (or other fundamental programming principles) for no good reason? Not so trivial.

Stack Exchange uses tables for layout (as do many of the other major websites that are making money). Does that make smoke come out of the purists ears? Sure it does. But pragmatism wins out over purity, every time. Shipping product wins out over getting it perfect, every time.

The whole domain layer, persistence layer, presentation layer, unit testing thing is still relatively new, from a historical standpoint. There are boatloads of software out there that still use a Client/Server model, and won't be changed to the latest architectural style just because it is "better."