In Vino Veritas

Life as a University Teacher


Happy New University 

Monday, January 4, 2010, ( 41591 views ) - University
A new year and a new university, namely the Linneaus University. Yay now that we are a "real" University all our troubles and pains are gone! Yay! Isn't it Great!

The Eternal End User Feedback Problem 

Wednesday, November 18, 2009, ( 12787 views ) - University, Web
So, I'm actually involved in a research projects now! My role is to act as a developer on a "digital marketplace for local produce". In plain English this means that I code a web application in php :P

Actually it's quite interesting to be on the developer side of a totally external project. That is I don't "care" about the project or manage it in any way I just do what I'm told to do. Quite refreshing not having to meddle in every aspect development as I'm used to. Also interesting to spot problems in the project...

The biggest problem we have is "end user feedback", that is we don't get any.

This is a sure sign of a project to fail miserably as we can't deliver value to the end users if we don't know what they want, and they don't know what they want until they see what can be done.

This is indeed a complex problem and not an uncommon one either. I think the development organization needs to take a more active part in involving end users. Simply doing iterative deliveries does not work, you have to ask specific questions, ask end users to complete specific tasks. Also burning your bridges is a good thing, go public asap, don't keep the app in some artificial "development mode"! Force end users to get involved! Add obvious problems in the application, things that you know should be changed... This way user involvement could actually be measured.

That's an interesting idea... could probably be formulated in a ratio and you could state that the client must show some decided upon ratio of end user feedback in a contract (ie we have inserted 10 flaws in this iteration, we got 7 comments about them hence we have a 70% user feedback ratio)...

I really hope that we'll sort this problem out soon... for me it's a show stopper...

My first intention was actually to write something about CodeIgniter (php MVC framework) that has become kind of a love/hate thing for me... but this post is becoming long enough so I'll leave that to the next time :D

Smell: Big Operation 

Monday, November 16, 2009, ( 2831 views ) - Refactoring
You find that an operation in a class just keeps growing and it's becoming really big and complex as features are added. Having a big operation soon creates difficulties in understanding, maintaining and debugging as well as create "choke points" in development (many developers need to access/change the big operation at the same time).

Refactoring


Try to find logical sub tasks in the operation and refactor these to separate operations with good names and parameters. Spots to look for are logical code blocks like if-statmens, loops etc. These are all candidates to become new operations. You can also look for parts of the operation that operate on a single or a small set of attributes. This refactoring could be the starting point for breaking up the class in several smaller classes thus becoming the precursor to the refactoring in Smell: Big Class


Smell: Big Class 

Monday, November 9, 2009, ( 5240 views ) - Refactoring
You find that your class just keeps growing and growing as features are added. Some operations or work only on a subset of attributes of the class or there are clearly separated responsibilities of the attributes. Having large classes soon creates difficulties in understanding and maintaining the class as well as create "choke points" in development (many developers need to access/change the big class at the same time)

Refactoring


Find what operations work on what attributes, possibly even what part of the operations work on what attributes. Create separate classes for the different subsets with clear boundaries and responsibilities. Possibly a new or the original big class will be coordinating and distributing work between the newly created classes (i.e. a proxy or adapter like setup). In other cases clients of the BigClass should also be changed to work directly on the newly created classes.

You have something like this:


It can be refactored into this:


The "BigOne" class can then incorporate responsibilities that requires the use of several of the newly created classes.


Smell: Duplicated Code in Two or More Separate Classes 

Thursday, November 5, 2009, ( 3626 views ) - Refactoring
You have discovered that you are rewriting or copy/pasting a block of similar or identical code in two or more separate classes. Having duplicate code soon creates a maintenance nightmare where changes are hard to incorporate and bugs are hard to exterminate. The code duplication also makes the code base larger and harder to understand.

Refactoring


There are a few ways to handle this.

If your classes are already part of a inheritance hierarchy then you could refactor the duplicate code into an operation in a suitable superclass.

You have something like this:


It can be refactored into this:




If you don't have a superclass you could create one and refactor the duplicate code into an operation in this new class, and then use inheritance to share the code. Possibly one of the existing classes should be promoted into a superclass.

If for some reason (possibly there are other classes that should not have this functionality forced on them and/or using inheritance is unsuitable for semantic reasons) you don't want to promote the duplicate code to a more general superclass you should possibly encapsulate the duplicate code into a separate class and use this new class in some way.

You have something like this:


It can be refactored into this:


| 1 | 2 | 3 | 4 | 5 | Next> Last>>