Monday, August 2, 2010

Am I getting something wrong? (thinking about OOP)

Maybe I am totally wrong but here is what is in my mind. Most of the books that describe object oriented programming, architecture or whatever are making examples using “objects” like person, cat, mammal and then big hierarchy of classes. Of course, more advance books are explaining why huge hierarchy of classes can be wrong and why it is good to use composition. I will not even try to explain that in this post.

And then having these classes you can read about different aspects of OOP. Some of the examples can be:

And I agree that these are almost great examples (except person.openDoor() where I will come back later on).

So let me try to explain where are I am aiming with me question (in the caption of the post).

For learning OOP these may be good examples but from my experience so far these are cases that I don’t meet so often in practice.

Let try one example. Imagine class Can (not verb but noun). Coming from the examples above one could model method: Uhmmm, is it really possible that Can is able to open itself? I wouldn’t say this is reality.

So what is solution here? Quite straight forward. Model a class CanOpener. Then model method can). This is now much closer to reality.

But what is Can and what is CanOpener from the programming point of view? Well I would say:
Can - is data
CanOpener - is service

And in most of the projects this is what I meet. Most often you are working with data and then perform something on that data. If you try to model your solution as explained at the beginning of the post you will finish with domain classes that have hundred of methods and probably thousands of lines. But very often domain classes are just data while services are actually performing real work. But be careful not to fall into trap of procedural programming.

So come back to example from the beginning: person.openDoor(). As I mentioned this is not good example. And again I would model this quite differently:
DoorOpener (interface)
Person (implements DoorOpener)

It is clear that doors can be opened by person, but they can be opened by engine or wind. So “item” that is able to open door is again service while door is just class keeping data (entity). And yes, you need to add code to open door into Person but again this can be great situation to use composition.

I hope I successfully explained how I try to model solutions for programming problems.

And just short note at the end. Please do not add Service, Manager or similar words at the end of class name. It can easy trap you into procedural programming as you will place too much responsibility into those “managers”.

Saturday, July 31, 2010

Starting with Startup - Agile Acceptance Challenges

When starting with the agile development (Scrum as base in our case) there are always some challenges that you will meet at the beginning and during the road.

I will try to explain structure of the team and acceptance of different agile parts.

We have started with team of 6 (including me). Two of us already had experience with Scrum, one of us had experience with classical water-fall models and three had no experience with project management models. Few months later the team was extended with the tester.

The structure of the team was (is) following:
3 senior developers - 2 with agile experience and 1 with water-fall experience
1 intermediate developer - experience only with ad-hoc project management model
1 junior developer - no experience with any project management model
1 designer - no experience with any real project management model
1 tester (few months later) - experience with water-fall models

So let see how this team went through agile adoption.
For each part I will split acceptance into three parts:
- with agile experience - acceptance of the team members who had agile experience
- no experience -acceptance of the team members that had no experience with project management methodologies
- water-fall experience - acceptance of the team members that had experience with water-fall project management models.

Writing requirements (user stories)
With agile experience
Team members that already had agile experience had no issues in writing user stories.

No experience
Team members without experience with project management methodologies accepted user stories as the form of writing requirements. At the beginning there were some issues to write user story of the right size (sometimes they were too small or too big) but they got the right form very quickly.

Water-fall experience
In the case of developer user stories have never been really accepted. My feeling was that there was no even wish to understand what is advantage of user stories. User stories were constantly too big (e.g. As admin I can do anything). Actually this colleague have never accommodated to agile development and left the company later.
In the case of tester acceptance of user stories came much faster. For him it is much easier to understand what to expect when user story is implemented. It is obvious that tester prefers user stories than complex use cases or other functional specification.

With agile experience
Surprisingly here we needed some time to accommodate. The reason was that I have decided to use story points as estimation method. But the team member with agile experience was used to ideal person days estimation. It was confusing for him for some time. But at the end estimation model with user stories was fully accepted

No experience and water-fall experience
After some turbulences at the beginning estimation model was accepted. The most issues were regarding over-estimation and under-estimation. But with help estimation became better and now is constant.

Meaning of DONE
Meaning of DONE in agile is very interesting. You should finish user story in the way that in the future you should not come back to that user story. User story should be ready for production.

With agile experience
Anybody with agile experience should not have problems to get meaning of DONE. At least that was the case with us.

No experience
At the beginning it was not so clear what DONE means. There were questions like: Is it already DONE? Can I improve this? I have such good idea, can I add it?
All the time I have insisted only on implementing user story and focusing on tasks. Very soon they realized what done means and actually realized why DONE is very helpful.

Water-fall experience
Here situation was much more interesting.
Developer with water-fall model experience had constant problems to get work DONE. There were always small tasks that can be easily finished later. There were always some missing features because they were not specified enough in the user story description. The "wrong" influence of the water-fall could be felt most of the time.
But tester was much happier. He read user story and had understanding what to expect from it. This way he can test and easily see if it is DONE. There are no answers like: I will do it later. It quite simple - if you sent user story for testing everything must work.

Under "testing" I mean writing unit and integration (as we use Grails) tests. Here situation differs from team member to team member. Some of them understand and know how to write good tests and some of the are still fighting to get the tests right. The most common issues are like:
- writing test that tests too much functionality and spread through number of classes or services.
- writing test that tests method not functionality

My feeling is that team accepted agile development very good. For team members without project methodology experience agile acceptance was easy and what is the most important natural. They have feeling that it is the right way to do the work. The most problems had a developer with water-fall experience. But the proof that having water-fall experience does not mean it is impossible to accommodate to agile is new team member that also came with water-fall experience but is accepting agile approach very good.

What is your experience in accepting agile?

Thursday, June 17, 2010

Starting with Startup - Minimizing Unknowns

In the previous post I have explained some reasoning why have we selected certain technologies, tools and processes. As mentioned all decisions were made to minimize number of unknowns in the project.

So process was selected in a way so we can adapt easily - means Agile.
Tools and technologies were selected according to project needs and common knowledge of the team.
Hopefully team will get know each other as time passes by and I have believed that everything will go fine (and mostly lucky for us that was the case).

But the biggest unknown was still there - PROJECT.

You cannot start development before you know what need to be implemented. Just having list of user stories would not be enough. You have to understand similar projects, you need to feel similar projects, know what are your main differences and how to use them to be successful.

Or in short - team has to share the same VISION.

And next few sprints were devoted exactly to this. Project investigation. We have been doing 1 week sprints and each project member was investigating different aspects of the similar projects. We have studied things like:
  • features
  • user interface
  • easy of use
  • lot of discussion with product owner to get feeling what are his main ideas

At the end of each sprint we had demo. Demo was used to present in details what are doing similar companies (should I say competitors :) ). This way all project members (including product owner) were able to better understand what is expected from us and in which direction we should roll out project.

We did couple of week length sprints and when we have feel confident enough we were able to start with the project.

So let summarize steps we did so far:
  • process selection
  • team educatin
  • tools and technology selection
  • project investigation

And now we are finally ready to start with the project. So in next posts I will describe some challenges we had during project development. Stay tuned :)

Monday, May 31, 2010

Starting with Startup - Tools and Technologies Reasoning

For those that read 'Starting with Startup' posts I want to apologize for not writing recently but last months we have been working a lot. You know how it is in startups :)

In the previous posts I have explained processes and tools we have decided to use. There were some comments and questions why this and not that technology and similar.

When you start with the startup everything is completely new. The following list captures the most important new things that each member of the startup team meet:
  • team members
  • project
  • processes (you cannot expect that each team member will have experience with the process you select)
  • technologies (you cannot expect that each team member will have experience with all technologies you select)

As we all know it is much easier to predict result if there is minimum of unknowns. And in the startup company more or less everything is unknown - from the project to the project acceptance from final users. So what you try is to minimize unknowns. And to do that you have to carefully select each aspect of the technology and process.

I would say that selection of agile and Scrum is more or less straight-forward. You want to be able to adapt to each new situation that will come up and what gives you more possibilities for that than agile development.

How to minimize unknowns in the project will be topic of further posts.

And at the end comes technology. And here is reasoning similar. You select what suites the best for the team and the project that is in front of you. And that is reason why we didn't select some upcoming technologies like GIT. We have created list of tools we need and then selected those that are the most known to all of us. And the result of selections are in details explained in the previous post.

Monday, February 15, 2010

Starting with the Startup - Setting Up Development Environment

After we have set basics for using Scrum we can start with our first sprints. Our first sprints were devoted to choosing and setting up development environment.

So let explore what do we know so far about the project (of course I knew much more than I can write in this post).

* Our main focus are desktop and mobile web applications
* Our core business is in the field of affiliate networks
* We will use agile process or to be more specific Scrum

So I will jump directly into decisions we had to make and what have we decided:

Web development framework
Basically we have been deciding between two choices: Grails and Wicket. Who is reading my blog from time to time probably already knows answer to this. We have decided for Grails.

Build process
Although Grails have nice build commands we needed something that is easier to integrate with the builds of other projects. Basically we have been deciding between maven and ivy. As Grails supports ivy much better than maven we have decided for ivy.

Continuous build process
More or less we have not been thinking too much here. We have decided for Hudson. Hudson is easy to install, has great front-end for management and number of very useful plugins. One note: although Hudson has Grails plugin we are not using it. We are using ivy in the Hudson to build the Grails projects.

Bug tracker
Although we would be happy not to have bugs that is not reality. So we needed bug tracker. As most of us had experience with Mantis we have decided that our bug tracking tool will be Mantis

Libraries repository
We will be depending on some external libraries. As we don't want to have them stored on Internet we needed some tool that handles dependencies. We have decided for Nexus.

Source code control
Although there are new source code control system like git we have decided to use probably the most common one Subversion

Mobile web development framework
After lot of investigation you find out that the market with the mobile web application frameworks is quite poor. The only available and really useful open source solution is: WALL NG. Luckily we have managed to almost fully integrate WALL NG with the Grails.

IDE Tool
Although we didn't have any experience with InteliJ Idea as this is currently only tool with good support for groovy/grails we have decided that our IDE tool of selection is InteliJ Idea.

In-house Grails plugin repository
As Grails has number of useful plugins and we knew we will be using them. This leads that we need local Grails plugin repository. Grails repository is set in the Subversion.

Having setup like the one mentioned above should give you fluent build process that is easy to repeat in the any moment. Additionally Hudson will ensure that your build is in the fit condition because it will report all build and test breaks.

Thursday, February 4, 2010

Starting with the Startup - Start Using Scrum

After Scrum has been selected as process and the team have been educated about agile and Scrum we can start with setting up development environment. Very important thing to notice is that we can start using Scrum right away. Yes, Scrum can be used for tasks where you need to make decisions, investigation, setup of development environment and similar tasks.

As quite often those tasks are not too much time consuming and you want to review current status more often it is best to start with short sprints. E.g. we decided to make one week sprints. This means that you can review your progress, adapt to new findings and adjust your directions on the weekly basis. When you are deciding about length of the sprint you should ask question: For what time period can we be sure that we will not change our minds?

The first thing we did was not part of the sprint but we did that with the purpose. We wanted to select some Scrum tool.

More or less there are two basic options:
* Using excel for product backlog and sprint backlog
* Using some of existing (commercial or open sourced) Scrum tools

We have decided to use ScrumWorks basic edition with the addition of the big pin-board.

ScrumWorks enables you to have product backlog, sprint backlog with the burndown chart, and some advance reporting options. Pin-board is used for user story cards. Idea is to split the pin-board in columns (e.g. todo, progress, testing, done) so everybody can see the status of the current sprint by simply looking onto it. If you are asking: isn't Scrum tool enough, I would say no. The reason is that if you are not part of the team, to check the status of the sprint it is enough to check the pin-board. Without pin-board you would had to open Scrum tool and this is already enough to give it up on checking status of the sprint.

One of the most important features of the agile and Scrum is transparency. We want to be aware of the real situation in each moment. If the project or sprint is late we want to find it out as soon as possible.

So we have prepared our Scrum tools and now we are ready to start sprint(s) for setting up development environment.

So how we set up development environment will be described in the next post.

Sunday, January 31, 2010

Starting with the Startup - Educating the Team

In the previous post I have explained why we have choose agile approach or more directly Scrum. But before you start using agile approach it is very important to explain what is agile and Scrum to the whole team and of course to the management.

In our case we are lucky because we have full support from the management. It means there are no "artificial" obstacles in implementing Scrum. The only real obstacle are we. So before going on I made presentation about Scrum, team members did some reading and then we discussed about the whole approach.

So when you are educating team do not forget to explain to them:

  • Cores of the agile and the Scrum

And especially take care to explain:

  • Why everything in Scrum is time-boxed
  • What is user story and what are the differences between user story and use case
  • What means DONE
  • What is goal of the sprint
  • What is velocity and why it gives better estimation when things will be done than "classical" approaches
  • Why testing is so important in the agile approach
  • What is burndown chart and how it helps the whole team

It may be clear why these points are important but I will shortly explain why I think it is important to take care there is full understanding of them.

Time-boxing - very often developers are used to implement some tasks as long as they want. Even after deadlines. In Scrum everything is time-boxed because this way everybody have to be focused that features have to be finished in proposed time. So it is not possible to change architecture forever. In one moment you have to decide and do implementation.

User story - in lot of companies and even in schools developers are used to thing in use cases. While use cases are good very often they put limitation that need not to be set in given moment. Classical examples are: then user clicks the button.... How the use case knows there is .... button. User story explains functionality that user wants to achieve without too much details.

Done - Done must mean: I am confident that feature implemented can go online. It is tested, written in good quality and I believe there are no bugs. This should be approach for all features that are marked done. You should not return back to this feature.

Goal of the sprint - you have to set goal if you want to have good feeling at the end of sprint. How could you know if your sprint was success or failure without clear goal?

Velocity - velocity is number that based on the experience (yesterday's weather) tells you how much team can implement in the given period of time. Velocity is better than "classical" approaches because it covers meetings, phone calls, unexpected bugs and everything that is happening more or less regulary.

Testing - if there are no tests how can you change the code and be sure that you didn't break any of the existing functionality. Well you cannot and you have to check everything after each change. If you have lot of tests you just run them and find out immediately if you have broke some existing functionality.

Burndown - is great tool that tells you without mercy you current status. It will tell you if you are doing good or if you are doing bad. Just have it in front of eyes.

Conclusion: If you have decided to take agile approach do not forget to educate developers what is agile. It is better to do it at the beginning then fixing problems in the middle.