If I had the power I would just fire him.



  • One certain developer got some simple task that would have involved the modification of one or two files.
    After one week of work and a messed up project that doesn't work anymore, I fired up bash to do some svn log.


    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn log -l 20

    r4837 | developer | 2012-07-24 12:13:58 +0200 (Tue, 24 Jul 2012) | 3 lines

    DevIT#158667

    • set output directory to the one of the slce test environment. needed for package creation

    r4835 | developer | 2012-07-24 11:35:47 +0200 (Tue, 24 Jul 2012) | 3 lines

    DevIT#158667

    • do not move genericsubcsm after building

    r4831 | developer | 2012-07-24 11:13:04 +0200 (Tue, 24 Jul 2012) | 1 line

    removed copy of GenericSubCSM from buildscript

    r4830 | developer | 2012-07-24 11:07:37 +0200 (Tue, 24 Jul 2012) | 4 lines

    DevIT#158667

    • generic csm is now a csm instead of an exc
    • Downgrade of RTCosmoTesting to 1.2.08

    r4829 | developer | 2012-07-23 15:19:40 +0200 (Mon, 23 Jul 2012) | 3 lines

    DevIT#158667

    • generic csm is now a csm instead of an exc

    r4827 | developer | 2012-07-23 13:45:28 +0200 (Mon, 23 Jul 2012) | 3 lines

    DevIT#158667

    • Reverted new Code Generator

    r4826 | developer | 2012-07-23 12:44:07 +0200 (Mon, 23 Jul 2012) | 5 lines

    DevIT#158667

    • added code generation for generic csm
    • generic csm is now a csm instead of an exc
    • added ods/xml for GenericTestCodeSubCSM

    r4821 | developer | 2012-07-20 16:19:52 +0200 (Fri, 20 Jul 2012) | 5 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01
    • new dia.ecore
    • CMakeLists.txt update

    r4819 | developer | 2012-07-20 15:59:28 +0200 (Fri, 20 Jul 2012) | 5 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01
    • new dia.ecore
    • CMakeLists.txt update

    r4817 | developer | 2012-07-20 15:52:43 +0200 (Fri, 20 Jul 2012) | 4 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01
    • Removed Generator and ods from project

    r4816 | developer | 2012-07-20 15:52:01 +0200 (Fri, 20 Jul 2012) | 4 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01
    • Removed Generator and ods from project

    r4809 | developer | 2012-07-20 13:28:45 +0200 (Fri, 20 Jul 2012) | 3 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01

    r4808 | developer | 2012-07-20 13:25:04 +0200 (Fri, 20 Jul 2012) | 3 lines

    DEV#158667

    • integration of new RTCosmo3Testing 1.03.01

    r4805 | developer | 2012-07-20 11:08:11 +0200 (Fri, 20 Jul 2012) | 9 lines

    DEV#158667

    • add ant script for the infrastructure of the SLCETest_Generator
    • add pycsmbuilder support
    • add example project
    • add packaging of jar
    • add SEInfo.xml with dependency on the ods2xml generator
    • fixed generation of InternalOnly events in SubCSM
    • added CMake support to project

    r4804 | developer | 2012-07-20 11:00:57 +0200 (Fri, 20 Jul 2012) | 2 lines

    • added ant script for the infrastructure of the SLCETest_Generator

    That's quite a lot of work! Let's have a look at one of the files:

    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -c 4816 GenericTestSubCSM/CMakeLists.txt | diffstat
     CMakeLists.txt |    6 ------
     1 file changed, 6 deletions(-)
    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -c 4826 GenericTestSubCSM/CMakeLists.txt | diffstat
     CMakeLists.txt |    9 ++++++++-
     1 file changed, 8 insertions(+), 1 deletion(-)
    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -c 4829 GenericTestSubCSM/CMakeLists.txt | diffstat
     CMakeLists.txt |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -c 4835 GenericTestSubCSM/CMakeLists.txt | diffstat
     CMakeLists.txt |    5 ++---
     1 file changed, 2 insertions(+), 3 deletions(-)
    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -c 4837 GenericTestSubCSM/CMakeLists.txt | diffstat
     CMakeLists.txt |    5 +++--
     1 file changed, 3 insertions(+), 2 deletions(-)
    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ 
    

    I didn't even expect that you need to modify this file. And why are there as many changes?
    Ok, let's have a look at how the file has changed from the original version:

    me@computer:~/Work/InstrumentControl/LIB_SLCETestEnvironment$ svn diff -r 4815 GenericTestSubCSM/CMakeLists.txt | diffstat 
     CMakeLists.txt |    1 +
     1 file changed, 1 insertion(+)
    

    Just a single line?


    Index: GenericTestSubCSM/CMakeLists.txt

    --- GenericTestSubCSM/CMakeLists.txt (revision 4815)
    +++ GenericTestSubCSM/CMakeLists.txt (working copy)
    @@ -31,3 +31,4 @@

    set output directory to the one of the slce test environment. needed for package creation

    SET_TARGET_PROPERTIES (${PROJECT_TYPE}${SEID}${PROJECT_NAME}_${LONG_VERSION}${DEBUG_BUILD_FLAG} PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/../SLCETestEnvironment/Build/bin)

    Wow, five check ins to add a single empty line. That's not bad. Unfortunately other commits by this developer include other changes than empty lines. If he only would just commit empty lines, than I would not really care about it.



  •  Is this developper in some kind of "auto-commit on file save" mode?



  • @tchize said:

     Is this developper in some kind of "auto-commit on file save" mode?

     

    Maybe his editor does that.

     



  •  What do the log files say when checking in a blank line? If the log says "integrating ...." or such, then it is obviously a false entry, and I'd fire him.



  • Does the place pay by the commit?



  • One time, I saw the lead developer change a single line, commit the change and TAG the project.

    That, and his tendency to over-engineer everything, made me glad I left that project.



  • @ggeens said:

    One time, I saw the lead developer change a single line, commit the change and TAG the project.

    That, and his tendency to over-engineer everything, made me glad I left that project.

    Was his name Brian?


Log in to reply