09 January 2012 ~ 4 Comments

Question: What does “productivity” mean to you?

A little while ago, I asked a random sample of Castalia users to complete a survey. The primary purpose of this survey was to get feedback on how I can make Castalia better, and I tried to ask questions that would both tell me what I’m doing right as well as where I can improve.

One of the questions was “What is the primary benefit that you have received from using Castalia?”

90% of the respondents answered the question, and OVERWHELMINGLY, the responses used words like “productive” and “productivity.”

The thing is, “productivity” is one of those sort of late-90′s business management buzzwords that has come to mean so many things that it’s just about meaningless. So here’s my question for you: What does “productivity” mean to a Delphi developer?

I’ll start: I think that a productive programmer does three major things:

  1. Writes better code faster
  2. Understands code (whether his own or someone else’s) better, and faster
  3. Improves old code accurately (and faster)
As a programmer, what does “productivity” mean to you?

4 Responses to “Question: What does “productivity” mean to you?”

  1. Michael Thuma 9 January 2012 at 2:24 pm Permalink

    Effectiveness, but this is one word for A) B) C)

  2. Medium 9 January 2012 at 5:37 pm Permalink

    I feel most productive, if my set of tools allow for a “smooth flow”. Meaning: I do not feel obstructed by them while thinking and coding highly concentrated on my task, for some longer period of time, like hours.
    If I can just write and write and spit out into the editor what I think in that moment, a lot of work can be done very effectively.

    So, for me, in case of tools, it comes down to two major aspects:
    1) It provides the right functions for my task and style of working.
    2) It provides it’s functions through an interface (graphical, keys, smart behavior, …), I can learn fast to use without having to think about it at all when coding. Both are essential, as one without the other certainly does not lead to anything near productivity.
    When going straight for function, I’d say if a tool automates “dumb” tasks that consume much time doing by hand, would be one of the strongest factors.

  3. Rich Snyder 10 January 2012 at 12:53 am Permalink

    Productivity for me comes down to Correct SLOC / Hr.

    So, the tool needs to help increase the number of syntactically correct lines of code that I can produce in an hour. The structural highlighting is a great help in understanding the software to ensure functional correctness and this can help with maintenance and refactoring.

    So, the ability to produce the lines of code is key – code templates, inline variable declaration, rename local variable / parameters, syntax checking and add parameter all greatly increase the ability to write the code. I have to type about 2 letters in most instances to get to the keyword I need and then move on to the next part of the expression.

    I especially like the inline variable declaration – nothing slows things down like having to browse up to the top of a method to declare a variable. I find that fantastic to be able to declare and not have to move around.

  4. adrian dentser 10 January 2012 at 5:24 am Permalink

    Productivity is a meaningless term.

    The most effective programs in my experience are those written by an expert in the problem domain, someone that absolutely understands the business or use cases.

    On the other hand, such experts are very rarely programmers. They use Visual Basic, MS Access, Excel or even script languages.

    Other professionals from that field put up with its oddities and catch on how to use and even to modify it because they, too, understand the problem domain.

    Then someone decides to port it to a “real” program. Management layers are introduced. Programmers are hired with no knowledge of the problem domain. The programmer team has no contact with users, costs swell, slippage is tackled with meetings, progress reports, more feature promises, introduction of UML tools, Agile methods, a department that creates unit tests, etc. Productive, yes.

    Finally the project is stopped and the old tools are still used by the professionals.


Leave a Reply