Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am looking for a programming task, which shows whether the coder has maintainability in mind while programming. I imagine giving a task to fix a bug in a method. It should be clear to the programmer fixing the bug that this bug was caused by code being unmaintainable. The perfect solution would be to rewrite the method so it becomes maintainable.

Do any of you know any such tasks? I use PHP, but I am interested in examples in any language.

share|improve this question

closed as not constructive by Jim G., Glenn Nelson, Yusubov, Caleb, gnat Feb 11 '13 at 7:36

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Considering that code usually needs to have a large number of lines to become "unmaintainable", and job interview questions require short code snippets, I don't think this is actually possible. –  user16764 Feb 10 '13 at 23:39
Why the closing vote? –  David Feb 10 '13 at 23:47
@user16764 I have seen 10 line methods that are unmaintainable. –  David Feb 10 '13 at 23:48
For me the big question is, are the requirements and design of good quality, these lead to maintainable code. Caper Jones suggests these factors have more impact on code quality than having a very skilled programmer. en.wikipedia.org/wiki/Capers_Jones –  eddyparkinson Feb 11 '13 at 2:05
I imagine giving a task to fix a bug in a method. Then what are you asking for? Also, how do you define unmaintainable? Seems to me that if you can fix a bug by rewriting some code, by definition you will have performed some maintenance and the code therefore wasn't unmaintainable after all. –  Caleb Feb 11 '13 at 4:12

3 Answers 3

Source code needs to be maintainable only in a degree that relates to the rate of changing conditions. So to test for the maintainability of source code you need to measure what changes have upon the source code.

To create a task for a programmer to test their ability to write maintainable code. I'd recommend doing it this way.

  • Tell the programmer the task involves 3 steps, and they will be given instructions for each step after the previous one is complete.
  • When the programmer finishes a step. They must submit their source code changes before receiving instructions for the next step.
  • Step 1: Instruct programmer to write a simple software program that sorts an array of products to find highest, cheapest and middle priced products. Provide a fixed structure of that array as data they have to use. Instruct that it must stay as array.
  • Step 2: Instruct programmer to alter the software program so that it no longer uses an array, but a linked list of objects that represent what the data is.
  • Step 3: Instruct programmer to alter the software program to it no longer uses linked objects, but records from a SQL database.

For each step observe the differences in the source code. Measure how much of the source code has changed to complete the next step.

Highly maintainable code should proceed threw each step with fewest changes. How maintainable that source code is has little to do with how many lines of code it has. It's only the changes between requirements that matters, because that is what maintenance is changing something that already works.

share|improve this answer
This approach is you could end up with the wrong kind of developers - the perfectionists. The test will filter out most of those that consider YAGNI. –  mattnz Feb 11 '13 at 2:17
@mattnz Personally, I would never do this test with someone. Senior people would be offended, and junior people wouldn't be expected to pass. So what would be the point. Getting to know someone by building a friendship is the best way to judge the abilities of someone. –  Mathew Foscarini Feb 11 '13 at 2:23

Ideally, you'd focus on something that is called more than a trivial amount of times, as this is where code that is difficult to maintain would be the most annoying. This means focusing on a fundamental layer of the application, somewhere in the bootstrap process.

Asking someone to design an inversion of control (IoC) container and demonstrate it with two classes that sometimes depend on each other would be a good test, for bonus points you could stipulate that the classes should also decouple nicely from the IoC container itself. If you want to be brutal, toss in a singleton requirement for one of them. While the task is not difficult to get right, it's not exactly trivial and also lends well to demonstrating someone's overall knowledge. It's easy for less experienced programmers to get this wrong.

The end result would most likely not be a lot of code, and give you a good indication of how well the person actually thought the problem through prior to diving in and writing it.

share|improve this answer
  • Ask the candidate to design a small application.
  • Try not to prompt for details too early. Let the candidate do most of the talking.
  • While they are explaining, record details that you think they may have missed.
  • At your discretion, you may ask follow-up questions or seek clarification.
  • Your notes should give you a pretty good indication if the candidate had maintainability in mind, even if he/she is not interviewing for a lead or architect position.
share|improve this answer
Thank you for your answer. I will use this while hiring freelancers over the web. I will not conduct any interview. I have removed the tag "interview", which might have mislead you. –  David Feb 10 '13 at 23:50

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