5

I have recently started work at a company using their proprietary CMS. Unfortunately, there is virtually no documentation for the application, and the source comments are also quite sparse.

Normally, given a particular task - I work down through the choices below, going to the next step if I can't find a solution

1: Consult the documentation (n/a) on how to do task X (i.e. create a page)

2: Read the source code - output variables - generally halt search after digging 4 or 5 steps into class/method chain

3: Ask the existing development team how they might achieve X in their application

4: Read the (uncommented) source again - go "rabbit hunting" - pursue each chain to completion

5: Make tea

On the one hand, my employer is looking for technical capability. On the other, they are looking for speed of execution. They are averse to me asking the other developer for assistance (despite the lack of documentation), yet seem surprised when I've then had to spend an hour (or two) rabbit hunting through their application for the origin of variable or method X. Bear in mind that I've been employed as an intermediate developer.

So, I wanted to get an outside perspective, is my process of elimination unreasonable? I can't imagine anyone writing a Zend Framework app without the documentation (and sometimes they struggle despite that...) - so working on some proprietary app with none is proving somewhat tricky.

sunwukung
  • 2,275

4 Answers4

3

Explain to them that the lack of documentation is slowing you down and see if you can setup a block of time with the other developer for him/her to teach you the CMS system. If they really do not want you bothering the other developer, at least let them be aware that it is slowing you down because you are having to figure out an unknown system on your own (a nice time to bring up something like that is when they say "hi how's it going" - answer with some variation of "slow because there is no documentation on how to use your CMS system and I'm having to figure it out myself")

Other then that, I've often found the best way to figure something out is to pick a task and get started on it. It will be slow at first, but as you work through it you often learn about the rest of the application.

Rachel
  • 24,029
  • I think you've hit the nail on the head. I am caught between wanting to being able to execute the task without assistance, and within an efficient span of time. Given that working through source is possibly the slowest route - I feel concerned that this will be problematic. As it is, I raised this issue today, and the line manager said that time is less of an issue at this stage than familiarising myself with the framework. – sunwukung Oct 05 '10 at 15:06
  • Yes, and offer to document what you find out in terms of some quickstart wiki or documentation which can then be shown to the next new person (to read and in turn improve)... should make most rational companies more receptive. – smci Jul 16 '11 at 20:08
2

I have found that actually jumping in and trying something, a step you have omitted, after scanning - or failing to find - the documentation often helps. Call an API function, see what happens, examine the return value if provided. Sometimes carefully reading the documentation first makes things seem more complicated than they really are.

ProfK
  • 512
0

You can normally find the problem easier if you do a straight back trace of the issue. Sometimes this is inefficient though, like when you have minimal documentation or knowledge of the system.

My suggestion would be let your employer know that this is an issue that prevents efficient work being done.

Josh K
  • 23,029
0

You might try convincing them that whether you spend the time looking for the solution, or they hire someone else, they are still spending the money to get a solution. It's not an easy, or quick, sell but they seem to not understand that. I worked for an employer with a similar issue although from a different cause. Their cause was lack of spending time on improving the framework. The end result is the same in either example.

frogstarr78
  • 231
  • I think it's a clash of philosophies. You have to draw a line between asking for someone to solve the actual task - but when you are digging through a chain of undocumented/uncommented methods - it seems wise to ask if any other developer has prior experience dealing with the issue. Of course, an alternative would be to document the code... – sunwukung Oct 05 '10 at 11:49