The Blog

World domination plans

published February 23, 2010

A minimal working product. These words seem to be very hard to grasp, I do not understand why. There is a study by the Standish Group, which claims that 45% of software features are never used and 19% are used only rarely. “This is something that we won’t need now, but will need it in the future”, I hear all the time. This kind of thinking is also very strongly present in RFQs (Request for Quotation). I call these world domination plans. A plan to build the greatest service from scratch and release it in a one big bang. “Not gonna happen”, I say.

Start with a minimal working product. This does not mean a crappy web page with animated GIFs and scrolling texts. No, it means a simplest thing that fulfills the most critical needs. Establish a constant flow of new important  features, minimize a lead time, and listen your customers. This is how you build the greatest services.

Samuli @ 20:15 (No Comments)

tags: Business, Customer, It should not be that hard, Lean, Process

Trackback URL

The roots of Alistair Cockburn’s Crystal methodologies

published February 17, 2010

I just finished reading Alistair Cockburn’s thesis People and methodologies in software development. I definitely recommend it for all people working with software and who are interested in software methodologies. Thesis raises important questions about group dynamics and I see a lot of interesting areas where social psychology could be applied. It also raises a question about the usefulness of software methodologies, as actual effect of a software process is  in reality quite small compared to personnel factors in a small project (see Software Estimation by Steve McConnell) although importance of process increases as size of the software grows.  As I said, highly recommended.

Samuli @ 20:40 (No Comments)

tags: Group dynamics, Methodologies, Social psychology

Trackback URL

Analysis of a successful project

published February 13, 2010

In a previous post I listed things that I consider important for a project to succeed. While writing the list, I constantly wondered how individual items are more of best practice, methodology and group dynamics related than expensive things you should buy.

A successful project must succeed in multiple areas. As seen on a picture below, there is no one magic bullet nor there is a one person making a successful project. It is a team effort and it will have to be started and managed accordingly.

In the picture above, there is an imaginary radar chart representing a project success on different categories. I think the items can be generalized into three categories: Execution, business and socials.

Execution contains actual implementation details, from methodology selection to coding, documentation and testing. Business contains business analysis, requirements,  calculations for return of investment, end users and other constraints. Sosials contains hiring a team, assigning roles for it and managing group dynamics.

So how do I come into this picture?
I usually work with roles such as “Scrum master”, “Technical Project manager”, and “Technical lead” and find myself working in all three sectors.

For people working in similar roles, it important to manage your own time and not to concentrate too much on one category. By concentrating too much on one area, you will cause damage for others. In the end, the success of the project is completely dependent on the skills of the people doing the job.

Samuli @ 19:26 (No Comments)

tags: Business, Customer, Group dynamics, Process, Quality

Trackback URL

When you absolutely cannot fail

published

Two days ago I had my wisdom teeth removed. It turned out that both teeth on my lower jaw were growing horizontally and their roots lied in the close proximity of nerves. In this case there is a small chance of nerve injury during the surgery. Luckily, everything went as planned, thanks to professionals who knew how to do their job.

Of course in these cases you will want absolutely the best people on the job. Last night before the surgery I wondered what is a IT equivalent for this case, what do you do when your project absolutely cannot fail?

For this exercise to be reasonable, we have to give us some constraints. First of all, we cannot use multiple teams to do same job in parallel. Secondly, we cannot prolong implementation forever.

So what are the ingredients?

Hire a team

• Hire professionals.
• Hire people who are enthusiastic.
• Have variation in team.
• Hire people who are hands on.

Goal

• Have clear vision what you want to accomplish.
• Have clear goals and scope.
• Communicate vision clearly and often.
• Ensure that solution fits into overall strategy.
• Ensure that everyone involved knows your vision and goals.
• Ensure that project has senior management support.
• Calculate ROI.
• Know the problem solution solves.

Business requirements & constraints

• Know business requirements.
• Know availability requirements.
• Know anticipated user loads.
• Know non-functional requirements.

End Users

• Engage users early.
• Test high fidelity prototype with end users.

Team roles

• Project Leader; A Person who provides solid leadership for the project and manages it.
• Architect; A Person who is responsible of the architect and who also writes code.
• Tester; A professional who ensures quality with other team members.
• Developers; People doing design and coding.
• User interface designer; A person who is responsible for actual user interface design.
• User interaction designer; A person who will be making interaction design for the UI.
• Product owner; One person, who prioritizes backlog and knows vision inside out.

Methodology

• Use agile methodologies to deliver value in short iterations.
• Have clear definition of Done.
• Know your velocity.
• Continuous improvement using retrospectives.
• Do not let technical dept to pile up.
• Have a prioritized backlog.
• Have a release plan.
• Release often.
• Start up with minimal product.
• Use TDD.
• Use Personas.
• Have architecture guidelines and follow them.
• Have a coding standard.
• Develop an high fidelity prototype first.
• Have slack.
• Work closely with business.
• Work at sustainable pace.
• Have project status up-to-date and visible to everybody.
• Do pair programming now and then.
• Do formal design reviews.
• Do formal code reviews.

Technology

• Use proven technology.
• Use productive technology.
• Do not use just released versions of products.
• Beware of product/framework hype.
• Minimize used technologies.
• Know used technologies inside out.
• Focus on quality code.
• Do not let code clutter.
• Have clearly defined architecture.
• Use a Bug tracker.
• Use Version control.
• Write as little code as you have to.
• Implement vertical slices early.
• Keep it simple.
• Focus on rich domain model (Domain Driven Design).
• Do POCs when in doubt.
• Use set based design.
• Use static code analyzing tools.
• Use a profiler.
• Use Continuous Integration.
• Use a memory analyzer.
• Implement risky things first.
• Refactor when needed.
• Use design patterns.
• Buy tools you need.
• Have identical development, test and production environments.
• Use a web speed tester.
• Use caching.
• Focus on clustering early on.
• Make deployments as fasts as possible.

Documentation

• Have up-to-date documentation of core components.
• Use wiki.
• Document all implemented user stories.
• Document architecture from different perspectives.

Automation

• Automatize installations.
• Continuously automatize manual tasks.

Testing

• Have comprehensive test suite.
• Have unit and automatic acceptance tests.
• Test all documented user stories.
• Test performance early.
• Test security early.
• Do exploratory testing often.
• Test synchronization often.

Project management

• Keep it simple.
• Develop an initial project plan.
• Gather and analyze data.
• Manage risks.
• Know your budget.
• Do not micromanage.
• Keep meetings in minimum.

Group dynamics

• Believe in yourself.
• No part time members.
• Have team take ownership of solution and time estimates.
• Make the Quality a team effort.
• Celebrate success.
• Develop an enthusiastic and quality focused group prototype.
• Develop a learning environment.
• Share information.
• Minimize turnover.
• Develop a positive group affective tone.
• Develop a stop and fix culture.
• Collocate team.
• Have private and cozy workplace with enough room.
• Have good working conditions.
• Protect the team from outside disturbances.
• Make work fun.
• Coach team.

Huh, that was a long list and I am sure I forgot something.

Samuli @ 19:15 (No Comments)

tags: Quality

Trackback URL

Implicit personality theory and Halo effect

published February 3, 2010

It is funny how we categorize people when we first meet them. We all have automatic cognitive processes which help us to process huge amount of information available to us.  We associate particular behavior with our previous experiences and quite quickly decide what is this new person like when we meet her for the first time. This first impression is strengthened in our internal thinking later. So, getting the first impression right seems like an important thing.

In addition, if we find out that a person has one outstanding trait we have a tendency to associate other positive qualities for that person. This is called the Halo effect. For example in job interview you should look your best and try to really excel in some area.

Implicite personality theory on the other hand states that there are some traits when associated to a person will alter our general expectations about that person. A good example are words “cold” and “warm”. By describing a person intelligent, fast-paced and cold we will “freeze” the whole image. Suddenly “intelligent” does not sound same as it would if that person would be described as intelligent, fast-paced and warm. So it is not all the same how we describe a person, some words are more influential than others.

Samuli @ 20:15 (No Comments)

tags: Social psychology

Trackback URL

Future user interfaces

published February 2, 2010

Now that Apple revealed the iPad, Goole is showing a concept for Chrome OS with some pictures, Microsoft is working with Windows Surface as well as project natal, and Nokia is unveiling N900, you got to wonder if the new era of user interfaces is upon us. Natural ui is coming which will bring interesting times for web development. Generally, a developer does not make a great user interface designer and natural ui will likely to make things more complex for the poor developer.

In the mean time I would very much like to see progress in modular user interfaces and software development modularity in general. I am not talking about mere software reuse but more like Component-based software engineering. As our problems are growing in size, the need for modular applications is coming more and more evident.  There is absolutely no point of doing same thing over and over again.

Could there be a way to combine natural ui with something like component-based engineering? A platform that would provide needed ui components and intuitive user interaction that could just be hooked into a custom made service layer with a rich domain model?

Samuli @ 21:01 (No Comments)

tags: Future, Natural UI, Productivity

Trackback URL

Liferay front-end performance tuning

published February 1, 2010

As we are getting over 200 000 unique visitors on a busy day, we really must take a full advantage of the Liferay caching. In order to understand caching in Liferay 5.2.3, I had to dig pretty deep. There are multiple ways to increase the portal performance but the focus here will be the Liferay front-end.

The Liferay front-end caching is based on servlet filters and it basically provides four ways to enhance performance:

• HTTP header based caching
• Ehcache based caching
• HTTP response Minifier
• HTTP response gzipping

HTTP Header based caching

Liferay provides “com.liferay.portal.servlet.filters.header.HeaderFilter”, which can be used to manipulate HTTP cache-control. This your first line of defence.

Ehcache based caching

This one is the most tricky one. By default, Liferay provides “com.liferay.portal.servlet.filters.cache.CacheFilter” for caching requests in the Ehcache. Unfortunately, Ehcache configurations are buried deep. If you have Liferay source code, you should take a peek of files under “/portal/portal-impl/src/ehcache/”, especially files with a “liferay” prefix. Usage of these configuration files are configured in a portal.properties file using keys “ehcache.single.vm.config.location” and “ehcache.multi.vm.config.location”.

Underneath, The CacheFilter uses named cache “com.liferay.portal.servlet.filters.cache.CacheUtil” to store responses, which has time to live set to a one hour. The CacheFilter constructs cache keys like “HTTP:///WEB/FI/FRONTPAGE?NULL#FI_FI#OTHER#TRUE” from the request and stores rendered bytes into the Ehcache for later use.

It is configured to include specific resources in web.xml. If you need custom caching for your pages, you can do it with the CacheFilter.

HTTP response gzipping

By gzipping the response, round trip response time will be shorter. See a sample on SteveShoulds.com. Gzipping is done using class “com.liferay.portal.servlet.filters.gzip.GZipFilter”.

HTTP response Minifier

Liferay provides “com.liferay.portal.servlet.filters.minifier.MinifierFilter” which can be used to minify responses. It uses Yahoo’s YUI Compressor to compress e.g. css and javascript files.

Configurations

All filters are defined in web.xml and are already pre-configured. In order to change configurations you will need Liferay source code. It is easier to understand configurations by looking at the code.

Samuli @ 21:48 (2 Comments)

tags: Liferay, Performance tuning

Trackback URL