Return to 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?

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?