Next » — « Previous

How to Kill Projects

Published at: 06:08 am - Monday August 09 2010

When looking at the project kick-off process of some companies you really start wondering, what the heck are they up to?

These processes I am talking about look like this:

  1. Come up with an idea (I like that process step)
  2. Prepare a cost estimate and a business plan for the project
  3. Present these to a committee
  4. Update the documents from step 2. based on the feedback from step 3. (Its said that many comments are like ‘there should be a company logo on the title page’ or ‘you really shouldn’t center align the page numbers’)
  5. Present these to another committee which will decide on the funding of the project.

While this might be of some value of for large projects, it will kill small projects and put medium into trouble right from the beginning. For smaller projects the overhead of the approval process will not only delay the project  and increase the cost by a considerable amount of money. It will also kill of any motivation of anybody in favor of the project.

But it is even worse for large projects. Since once the project ha the approval, who will be inclined to question the project? Of course everybody will be bickering about the stupid idea the project is. But who does step up and says: “You know maybe the guys in control of my salary and career made a mistake and we simply should buy an of the shelve product for 1% of the money?” Correct: No one. The task of questioning the purpose of a project is done by someone else.

This would be OK, if the committee is in a better position to judge these decisions. But it isn’t it has the information of one person, carefully crafted for making sure the decision is made in favor of that person. You might assume just as well, they don’t have any information at all.

How about an approach like this: Give every employee a budget. Top people might get a bigger budget. Employees might invest into a project, or keep the budget. A percentage of the budget left over at the end of the year would get payed the employee. Another percentage would get added to the budget of the next year. When invested into a project, the investing employees get a certain part of the ROI of that project.

Certainly not the best solution. But certainly better then what is going on in companies right now.

Posted in: Management by Jens Schauder No Comments , ,

Be Persistent

Published at: 04:07 pm - Sunday July 25 2010

If you want to change yourself, you might be able to do it within 5 minutes. But if you want to change an organization change needs time. Even when you are the CEO, change doesn’t happen because you announced it on a big meeting. But

If you push towards change,

If you don’t give up,

If you try over and over again,

If you try different approaches,

If you talk to everyone who lets you talk,

someday change will happen no matter what your official title is.

Be persistent if the cause is worth it.

Posted in: The Rest by Jens Schauder 2 Comments

Properties of a Good Unit Tests

Published at: 06:07 am - Sunday July 18 2010

Question: what are the properties which make a test a good unit test? If you have a good answer, check out my answer and add to it in the comments. If you don’t here is mine.

Long Descriptive Name: For example returnsNullWhenCalledOnEmptyList is a nice name for a test

Simple Clean Structure: A test performs necessary setup, executes the method to be tested and performs its assertions. Not more not less

Fast: one thousand tests should run in less than a minute. This allows an extensive test suite to run often during development. If your tests are slower, you might be doing integration tests.

Test a Single Feature or behavior: This is sometimes phrased as ‘one assertion’, which I consider misleading. If you need multiple assertion in order to assert one behavior thats OK, although you might consider a new assert method for that.

Reliable: For the same code base a test should produce the same result every time. A test that fails every 10th time will fail for a real bug and you won’t know it.

Stable: The test only fails, when the code under test doesn’t behave as expected, not because anything else changed.

Easy to Understand: Just as normal code, the intention of a test should be easy to understand. Names help with this. Extracting setup code in a properly named method helps as well.

Should Not Use Production Classes, Except The Class Under Test: This helps with the ‘Stable’ and the ‘Fast’ property. It’s ok to use simple classes like String or Integer.

Don’t Try to Squeeze All Tests for a Class in a Single Test Class: For many classes you will have more then one test class. The different test classes will probably differ in the setup needed for the contained tests.

Independent: No Test should depend on any other Test or on the order of execution.

Posted in: Softwaredevelopment by Jens Schauder 4 Comments
Next » — « Previous