Hibernate Sessions

I have been using Hibernate for a very long time; at least nine years if not more. It is perhaps the best known ORM tool in the Java/.NET world today. There are many alternatives but none have the feature set or maturity of Hibernate. Hibernate is perhaps not the easiest tool to use, partly due to its long history, and partly because the problem it tries to solve is complicated, but you can get started with some basic information quite nicely. All criticism aside, it is still a fine tool for a general purpose ORM approach, and perhaps the best one to use for bigger applications.

Sessions seem like an appropriate place to start when navigating the Hibernate waters, so let us examine that topic.

Sessions

Working with Hibernate is built around sessions. This is the Unit of Work pattern, and to use Hibernate correctly, you must understand this concept well.

The pattern you use to work with Hibernate is as follows:

• Open session
• Begin transaction
• Using the session, query persistent mapped objects.
• and/or add new objects to session.
• and/or delete queried objects
• and/or modify objects queried or added.
• Commit transaction
• Close session.

This is your logical transaction, the Unit of Work that you perform, per action, in your application. Note that while this is often the same as a database transaction, these concepts are not equivalent. You may, if you so choose, open a session and transaction, query objects, make changes, flush those changes to a database (commit), open another transaction, make more changes, flush (another commit), and so on. One session, many transactions. This allows you to keep tracking all the changes that you are making but stage your database changes in several steps.

The same basic steps in C# code using NHibernate:

using (var session = sessionFactory.OpenSession())
using (var tx = session.BeginTransaction())
{
 var customer = session.Load<Customer>(customerId);
 customer.Name = "New Name";

 var newCustomer = new Customer(anotherCustomerId, "Another Customer");
 session.save(newCustomer);

 tx.Commit();
}

What do you get by doing this?

• all mapped objects that are introduced to sessions are tracked for their changes.
• once the transaction in committed, all those changes will be persisted to the database.
• all objects within the session are cached. Objects accessed by their IDs come from the cache if already there. This includes all session.Load/Get calls and objects loaded via relationships by their IDs.
• Hibernate can batch your updates to the database. Say you made 100 changes to objects, if you had set your batch size to 100, you will likely update everything in one database round trip. Hibernate is also smart enough to flush changes to the database when it needs to so you don't have to worry when to flush things manually. It is enough just to commit the transactions and close sessions as was explained.

Problems with Sessions

If you deviate from the mentioned session usage pattern, you will run into issues, and you will complicate your life tremendously.

Objects Outside Sessions

Hibernate does not know how to deal with any objects that it is not tracking within a session. You know when you have messed something up with the session management if you run into "non unique object", "not persistent object", "non transient object", "lazy loading", or "no active session" exceptions.

What these kinds of exceptions mean is that you are trying to interact with Hibernate with objects that were not introduced to the session, session was already closed, or the objects were introduced in another session (which now is obviously closed). All the objects that you want Hibernate to track, should be loaded, queried, modified, deleted in the same session. If not, then you must explicitly reintroduce (merge) objects back to the session. If you have lazy loading references, or collections, they can only be accessed within the same active session. Since lazy loading is an important concept to be utilized with Hibernate, it is also perhaps the most common scenario where the problems arise.

Lazy Loading and UI Rendering

People often use Hibernate loaded objects while rendering some type of user interface. A web page is typically rendered by passing some Hibernate objects to the view template engine. The problem with this is that objects may have lazy loading members that are loaded at the time of access only, not when the parent object was originally loaded. When a web page is rendered from the template, in may be that the Hibernate session is already closed because the control has already moved away from the code that programmers write (in a controller for example).

For this type of approach to work, the session must be open, even during page rendering. This is often referenced as the Open Session in View pattern. However, I can't openly recommend this pattern, while it solves the problem. It overlooks the fact that views are often composed from more than one action in real life, and are more naturally represented by individual sessions, one per action. Also, domain/Hibernate models are not often the same thing as view models and it might be better to actually translate domain (Hibernate) models to view models and back again to domain models. I am using the "domain model" here quite liberally, but distinctively as a separate concept from view models.

Many of us who use the MVC (Model View Controller) frameworks for our web application often struggle with the "model" concept. Typical frameworks do not really require anything from the M in the MVC, so developers are often left to come up with their own idea what the M means. Sadly, this will also lead to misuse of tools like Hibernate and more generally to mixing different layer concepts. The M in MVC is the mental model of the user (what user sees on the screen), not an internal representation of the domain (programmer's mental model). The domain model, incidentally, is what you load and manipulate with the help of Hibernate, but it is not the M in MVC. The controller (C) is where the translation between the mental models happens.

Session Infrastructure

Managing sessions means repeating a lot of boilerplate code, unless you use infrastructure. You want to hide session management in common scenarios so you do not need to worry about it a whole lot. Obviously, you must still be aware that all of that machinery is still there under the hood.

One of the best pieces of advice in this regard comes from Ayende@Rahien blog series about odorless and frictionless code. 

Note that this is done for .NET MVC, but many frameworks have similar hookup points to do infrastructure work. The action filter code in the example wraps around your action call and repeats the usage pattern boilerplate code that I explained. This is simply an "around advice" or "interceptor" in AOP terms.

It also demonstrates the point about "actions". There can be many actions in a web request, where each action executes a particular job for the page. Think of the actions like little windows or blocks on a web page that typical designs render, each separate from another. Sessions should last only so long as the action does, same with transactions.

Singleton or Simpleton?

Everyone knows that the Singleton pattern is bad, right? But is it really?

What is a Singleton?

The Design Patterns book says: Ensure a class only has one instance, and provide a global point of access to it. The motivation for this pattern is to have one instance of a class. The book continues that the class itself should make sure that there is only one instance.

Implementation

A lot of space in the book is dedicated for the implementation. It appears that it is quite tricky to create only one instance of a class. The book's example, and probably most implementations in various languages require use of static variables and methods. A typical implementation would look something like this:

public sealed class Singleton
{
   private static volatile Singleton _instance;
   private static object _syncLock = new Object();

   public static Singleton Instance
   {
      get 
      {
         if (_instance == null) 
         {
            lock (_syncLock) 
            {
               if (_instance == null) 
                  _instance = new Singleton();
            }
         }

         return _instance;
      }
   }

   private Singleton() {
      //Prevent new Singleton().
   }
}

• Lazy initialization with double locking. Create one only when it is needed.
• Volatile instance variable to ensure atomic creation and assignment.
• Thread safe. Uses a separate lock object.
• Prevents new operator.

Getting it right is not that easy and usually requires quite a bit of knowledge.

Is it Evil?

Let us list some of the most commonly mentioned "evil" things:

• The Singleton code is hard to get right and it instantly becomes boilerplate that you copy to other Singletons over and over.
• Singletons are shared instances, and so they must be thread safe. This easily forgotten fact causes many unexpected problems.
• Can't really subclass a Singleton - you will break Liskov and other OOD principles to do this.
• Related to the previous; you can not make static instantiation functions abstract or virtual, thus negating any kind of abstract factory type behavior. You are stuck to tying the creation of the instance with the Singleton class itself. You can try returning an interface but it still requires a base class to know about its derivates directly or indirectly.
• Static method access allows you to hide API dependencies. Your API does not have to declare which singletons it is using inside. The behaviors that classes using singletons demonstrate can be unexpected and surprising - from the outset it is not obvious that code executes database queries, or does some other "magic" under the hood. Note that this does NOT remove dependencies, but it makes them implicit!
• Switching singleton implementations is hard and so, also, unit testing becomes hard. It might not be easy to do unit testing when you can not mock the behavior of the singleton, or you many not replace the dependent behavior at all because the code under test calls a singleton.
• Using Singletons (like any global) lavishly means that you are hard wiring your software leading to monolithic designs. When widely used, software starts to resemble procedural designs familiar from C and comparable languages.
• Singletons are Singletons, until they are not. We sometimes make a wrong design choice, or a bad prediction; what used to be ONE, no longer is not. Sadly, you are now stuck with it, and your only reasonable option in short term might be to break the Singleton and create many copies, usually by delegation or embedded factory inside the instance() function.
• Ever-lasting reference to the single instance can not be garbage collected without active "memory management". If your Singletons are big, and hold references to other things, you might be holding onto more stuff that you originally planned. 

But It is Popular!

All of that does not make the pattern very appealing, but still, there are always Singletons floating around. For one, some designs call for one instance of a class. It is quite legitimate to have such a requirement but somehow I doubt that the single instance argument made it popular.

Once developers learned how to create Singletons, as the Design Patterns book showed how, it became a very popular pattern to use. The appeal of easy access to one instance of a class made sure of it "success". Many design questions were now easy to answer - you just call for the Singleton when ever you need functionality of the object, right there in the code where you needed  it. You can do away with properties and constructor arguments, and you no longer have to concern yourself with having to hand in the dependencies the old fashioned way. From outside, classes look quite neat without those pesky argument lists and property pollution. Looks are deceiving.

It just became another way to go back to programming with "global variables". I also call these kinds of static accessor methods as a way to do "Russian doll design". You'd have to keep opening the Russian dolls to get to the bottom of the rather surprising functionality.

Implementation Dictates Context

What really hurts this pattern is its implementation. It is fine to have a requirement of a single instance, but it may not be fine to implement it with static variables and methods. When we talk about patterns, we also must remember what they are; design that solves a common problem within a context. Yes, within a context.

The Singleton pattern as presented above only exists in one particular context based on its implementation. That context is very limited to the utility of "static" variables and functions in the particular programming language. Yet, people treat it as a general purpose solution, and that ultimately dooms this pattern. Its utility might be very limited, contrary to its popularity.

Consider what happens across processes, or even class loaders that exist for many languages that have Virtual Machines. You can not guarantee a single instance easily with this kind of implementation and you may be surprised to find your application misbehaving if you expected to be safe from such things.

Utility Based on Context

Rather than bashing this pattern endlessly, let us expand the horizons a little bit and concentrate on the idea of patterns in a context. The Singleton "idea" is actually one that we use all the time, widely, in bounded contexts. The idea of Singleton - one instance in a context - is very useful.

To fix our approach to Singletons, we must first separate the creation of a Singleton from its implementation. In short, this means that the application of static members or functions is not allowed, and that any class can be a Singleton, or not, without us having to change anything about that class. We will only change the creation of that class, usually by configuration.

This is a solved problem these days, and has been for quite a long time. Popular Dependency Injection (DI) frameworks support the Singleton in different contexts. For web applications we might use "Request", "Session", or "Application" context, and DI containers like Spring can manage the context for you. We can also have the more traditional Singleton within a single container.

Anyone who uses DI frameworks has used these kinds of Singletons, and used them widely. Yet, we do not really think about it a whole lot, because we do not have to. The "evil" parts have gone away. Using Singletons like this, in a context, works naturally and there is no ultimate requirement to have just ONE - just one in a context.

Legitimate Uses of the Traditional Singleton

Since we talked about the context, there must be a context where the traditional Singleton approach is still valid. Let's call this a single instance in a process or class loader.

Typical examples include getting access to cross cutting features such as instrumentation or infrastructure that has to have a single point of entry in that context. A typical DI context might not be enough to solve this problem, and even the DI contexts must be created and initiated somewhere.

The traditional implementation still has many down sides with instantiation of different implementations, so what many approaches to "access roots" prefer is some kind of dynamic "service locator" that allows a configurable implementation:

var instance = Locator.GetInstance<IMySingleton>();

The service locator can choose the appropriate implementation, and can also choose how many instances are created. The access still clearly uses statics, which brings us many of the same woes that Singletons did, such as Russian doll design.

This may not be so bad with the named cross cutting infrastructure, such as logging, or configuration. Purists would still prefer to use techniques like AOP (Aspect Oriented Programming) to provide "transparent" logging and instrumentation, but this might not give enough insight to what you should log, for example. For practical purposes, you see log instantiation code similar to the example above.

Many, if not all, DI containers also double as service locators. However, this is not their primary mode of operation and they should not be generally used to fulfill this purpose.

But what about the actual traditional Singleton? It may just be that there are no real dependable uses for it, or  it should be very rare. We are still forced to deal with such code because we deal with libraries and other dependencies that use the Singleton pattern. Their use should be limited to as few spots in your code as possible.

Static Injection

I am going to mention one special case that came up recently, which involves DI containers and Singletons.

Having to inject dependencies during object creation can have its own problems. Sometimes people talk about Spring configuration hell, where injecting dependencies becomes nightmarish in the sea of hundreds and even thousands of classes. 

To combat some of these issues, it might be acceptable to use Singletons and static injection features of DI containers. Here you would let the DI container to call the instance factory function of the Singleton to create the instance, and then inject its dependencies. It is then possible to use such Singleton classes directly instead of injecting the instances. This approach can have the same alluring appeal to be replicated everywhere as the Singleton itself, but it also has most if not all of the problems.

Yet, this approach can have limited use:

• Make sure that the Singletons are used only in one closed and limited context. These Singletons may not be shared or reused between instances of several classes, for example.
• Do not use this approach for your business code, infrastructure, or code that is widely used as lower layers of your software where you can likely never guarantee that Singleton is the right way to go. Using this approach is OK only on the top application layer.

The Allure of Easy Answers

People are attracted to easy answers for difficult problems. We often refer these "easy answers" as fads once they gain popularity and some level of authority. The management fads are quite popular in our IT community for the simple reason that they attempt to answer the old problem of creating hyper productivity.

Many IT organizations are mired in problems creating results. If only those pesky developers would deliver what I want! Expectations turn into disappointments when the time lines are not what companies what, or  when companies can't fit their dreams into the budgets that they desire.

Agile! Yes, that will rocket our organization to unparalleled productivity. It's also very simple. I can see it fits on a pamphlet and it tells you what to do. Besides, they have Scrum Master courses, where within days you can now turn your organization into a well-oiled machine. All the experts say so, and we can hire Agile coaches who will come and rescue us if we get off the message.

Ok, so you are "doing" the Agile. You follow all the rules, and have your Scrums and Retrospectives, and Planning, and you tally up all the points and doodads. Cool, there is a graph that now tell exactly when we are going to be done! This is what management has been asking for all the time.

When the magic wears off then it does not look all that special. It sort of kind of works, but so did other things, sorta kinda. And, overall it probably is an improvement if you were stuck in Big Upfront Design. But, you can probably get the same just by having Medium Upfront Design, some work list, high level estimates that you keep updating, and some regular check point.

I remember tracking work on a spread sheet that would calculate the delivery date based on the task estimates ten years ago. This was the early days of Agile awareness for the greater public. However, any developer worth some gravy would already know the tools to be successful - hence the spread sheet. It's just that when you suddenly throw in a layer of bureaucracy and a Project Management Office in the mix when things usually take a nose dive. Welcome loss of sanity.

Suddenly some publicized Agile stuff starts to sound very good because it is marketable. You can sell that to a manager in a nice package, and you can give your graphs and velocity numbers to them, and boast about great progress. Yay! That's the antidote against PMO and layers of confusion!

But, I must admit that I am tired of the masquerade. I completely understand the Agile principle because that's what competent developers do on a daily basis, and have done so for a long time. It is just that when all those things that developers do to make things successful is marginalized, externalized and parcel wrapped into a "management fad" that the basic ideas of building software systems get lost somewhere. It's like a regression more than advancement when you start reciting Scrum commandments as the only gospel.

The problem is that fads provide easy and attractive answers. Unfortunately, you can only deliver successful stuff with great people. It's not the amount of people, but the kind of people you have. You still have to do the hard work, put the hours in, and be good at great many things. People are inconsistent, and they do not follow rules. Even if they follow rules, they follow them differently each time, with variable results. If something gets on the way, people stop doing it.

Because people are the way they are, you need adaptability, some light weight process, and interaction with feedback. That paired with good people will give you results. That same thing with wrong people hardly ever will. In fact, the process probably does not matter much. You can succeed with waterfall consistently if you have the right people.

Public Utilities

There has been some attention drawn to the recent state of some very popular Internet companies. On one hand, there is a talk about a new technology bubble on grounds of immense evaluation of some of these companies versus their actual ability to turn profits. On the other hand there seems to be recognition how fundamental these enterprises have become to the fabric of the Internet, and how people interact.

We have companies like Twitter, Yelp, Angies List, Facebook, Groupon, Salesforce and the list just goes on. With perhaps the exception of Facebook, these companies have not found a revenue model that is able to turn profits. Some of these companies have grown immensely, to meet the requirements to become intrinsic part of the Internet. But, what ever growth in income they get is consumed by their growth of work force, required to fuel the increasing demand for these services. The yield ratio is very close to 1 to 1, no matter what size the company.

To turn a profit, these companies would have to hire far fewer people, and in fact, not service the public at large. In other words, some of these companies make sense as a $10 million per year companies, but not as $100 million or something like that. The money is just not there to support profits.

Yet, these companies hire and support thousands of workers. They are being funded by venture capitalists in hopes that a business model is found that can turn a profit. But for right now, the evaluations of these companies is solely based on their mere volume of people they are servicing. Customers seem to indicate value, perhaps not now, but some day.

Perhaps, at least for now, you can call these companies public utilities. They are non-profits, funded by a sustainable model, and the growth is often funded by private money, and they service the public at large. They have become an intrinsic part of the fabric of the Internet. Apart from their basic services they often provide a value added interfaces that allow other enterprises to utilize their data in ways that they perhaps did not anticipate. These companies, perhaps, are something you can't control or buy in the traditional sense; you would fail to turn profit for your investment with high probability. In fact, you'd likely lose all value of your acquisition if you tried to change any part of their business with a profit motive in mind. Yahoo tried this with so many ways, and always failed - hence they are in the rut that they are in now. You see, the fortunes of these enterprises rests only on the approval of their users - one wrong move and you are done. Profit motives stink to high heaven with their loyal following.

These companies provide jobs. The jobs pay rather well. These people and companies pay taxes, and the government, hopefully, builds infrastructure to support the structures that make these kinds of services possible. There's probably not that much public money involved in creation of these companies but if the environment is set right, public money does support all this after all. It's a really good feedback loop to have and there are many benefits. The investors and Wall Street types may frown upon this on the long run, but capitalism should not support "finance" or "stock holders", but rather the society and public at large. Profit motives are only sustainable as long as that money goes to investments.

It is interesting that the Internet actually sustains models like these and keeps a kind of a honor system in place. People vote with their attention and time for all kinds of services that they deem useful. The bad ones die away. Tie some kind of "rip-off" mentality to your service and you will die a quick death.

Puzzling Hiring Problems

Developer Categories

So, you can't find a decent software developer to join your team? It should not be a surprise. Good developers are rare birds; very intelligent, introverts, detail minded, problem solvers, independent. I don't want to put people in a slot, but this is how developers often are. There just aren't that many sufficiently "brain damaged" people around who like to torture themselves with menial and time consuming problems that take deep concentration. You know, the kind of book worm stuff that people hate when they go to school etc.

You often see a a category of applicants who claim to know programming, but they don't. They usually fail even rudimentary tests that you put in front of them. They  are just fishing around, thinking that they can just grab a job and do a bit of good ole hacking on the side. These people don't really want to be software developers on the long run, even for the money. This group of people are a waste of time for anyone who wants to hire a software developer. They won't get much done, and what they get done, sucks.

We have software developers who tend to be careerists. They go to work and write software to get a pay check. They might be introverts and have some of the characteristics of good software developers, but they are only marginally committed. Nothing bad there. Most people you hire are probably like this. They get things done, but it's just not going to be anything more than average. They also mostly expect the work to be handed to them with full requirements and instructions what to develop.

And then there is the group, who is above the average. They care what they do, and they want to write software. They want to learn and they are motivated. These people are good hires, because they also get things done, and over time, they can do things that careerists just won't ever do.

The problem with the last group is that the ones that really have honed their skills are just not out in the open for the grabs, unless you are lucky. You simply rarely see them.

Engineer vs. Designer

Perhaps you have then hired someone suitable enough. They might be talented, and eager to do the job. They produce results and get things done, at times. But something just does not really jive. This seems to be true too; some developers enjoy the theoretical aspects of the profession, and some just like to slap things together quickly.

Either extreme does not work well. You don't want the architecture astronauts, or the cut and paste hackers, but you do want something in the middle range. This is because theory matters when it is put to good practical use.

You sometimes see people get stuck designing all kinds of lofty ideas that are not really relevant to the problem anymore from the practical perspective. It can be fun to think about, but it's a disaster waiting to happen in real life. It can take different forms; mindless use of tools that do not solve the practical and real problem (because in theory it could work), stuffing layers to software that only add to complexity (because it's what the best practices are). This is the designer trap that people sometimes get into.

Opposite can happen. Software is getting done fast, and quickly, but it is all in the name of getting it out the door in what ever way. It's bad software, hacky, copy pasted, sloppy, not well thought out, without any decent structure. Sure, it can work but only in small scale. Bigger software, critical software, and long term maintenance of software are those key areas where this kind of "getting it done" approach will create a disaster. It's perhaps what happens more often than over-architecting because things are being done and there is the feel of great progress. Managers especially love these kinds of people who turn around on a dime and "get things done".

To a significant degree these two kinds problems emerge from lack of experience. People are just good enough to produce results but the wisdom, intuition or true skill is not there to reign in the bad behaviors. Experienced people are simply far more balanced and know how to manage the outcomes.

Introverts and Extroverts

Some people are more social than others. Some people are more detail oriented than others. Some can solve problems better than others, and different kinds of problems. Some people are glib, some are not. What do you really want to emphasize in a developer?

There is the argument that now that we are doing all this Agile stuff that developers need to be really social and engaging, eagerly embracing the business, while at the same time you want them to produce brilliant, well thought out software that comes out like clock work, and never misses a deadline. Well, easier said than done.

I mentioned that most good software developers are really introverts. It's still true, in my opinion. It does not mean they are not social enough, but they are not the ones with the gift of the gab and "social engineers". They mostly focus on solving "non-people" problems that are eternally boring to the vast majority of people. These people stay focused on the technical aspects of getting things done, formulating complex things and making it real in terms of good software. It requires lots of concentration, free from unnecessary interruptions.This regardless of all the buzz about agile pairing etc. I don't think it always works; have never seen it work for real, in fact.

I think you want some kind of mix here as well, slanted towards the introvert types. If you want a good reliable software developer, you need that quieter type who gets things done with good workable design skills, who can still interact successfully with business and product owners when required. The onus for successful interaction is often put on the developer, but I think this is wrong - why not require equal attention and skills from business/product people when interacting with developers, to be able to understand enough what the developer is saying. IT functions are now so central to businesses that having business people who do not understand their IT operations is really a bad thing.

There are places for extroverts as well, in the agile realm of things. A good Scrum Master is often someone who's an extrovert, but they necessarily do not or should not lead software development from the trenches. Their focus tends to drift away from what is required to produce good software in practical terms. These kinds of people tend to jump around from one thing to another, relishing the opportunities to get things done quickly and moving on. Software development might interest them, but not in the sense that is required to become good at it.

The bottom line - don't expect developers to be socially gifted, while at the same time being great at building good software. It just does not work that way. We do not elect, nor often see politicians who are introverts, so why put unrealistic expectations on software developers? Brain, and the way it works matters when it comes to different kinds of jobs.

The Estimation Game

Recently, there has been various articles and blog posts about project or work estimation and whether it is worth doing.

What are the reasons for doing estimation?

• Know the size of work.
• Know the cost of work.
• Know the staffing.
• Know when you are done.

What can you estimate?

• Known requirements/features.

Challenges?

• Changing/unclear/missing Requirements.
• Knowledge of the Domain.
• Skill of staff.
• Changing Staff.
• Feedback/communication.

The reason for doing anything is to get reasonable value in return. The value that you expect typically is predictability. No cost overruns, work completed on time, and completed with the features as expected in working condition.

This sounds simple enough but it really depends. The problem really comes in with the size of the work.

Bigger projects have so much variability and unknowns that even the best attempts to estimate work up front will likely fail. It is hard to know what in fact will happen and the outcomes depend on the flexibility of the overall plan and the attitude of the team and the stake holders. The real problem here is that estimates become an unchangeable plan, and then they also become time commitments. When you fix these two things you have nowhere to go when surprises occur and new work is invariably discovered. On the other hand, if you are flexible, large swaths of the project plan might change on the way and budgets and time lines might actually have less relevance in the overall process. Also, the human component is so dominant in long running projects that it is very hard to guess what the output of the team is, especially if the team keeps changing along the way.

Smaller and often unrelated work items can be estimated quite easily and there are far fewer surprises. However, this kind of workflow often has so much flexibility that the work plans keep changing from week to week. Many of the items that are estimated will never be worked on and new items are inserted to the work flow. It might be that there is a lot of churn and time spent on estimates but at the same time it is quite well known how soon work is completed when it is started anyway. If you put a work item on top of the priority queue you can expect it to be done within the iteration, as will many other items reasonably close to the top of the list. Further down in the list the item is, less you really care about it, and the stake holders might never really care about it at all after couple of iterations.

So, where is the value? I think the only real value is the ability use living estimates as a decision making tool.

In the long running projects, you only care what the estimate is NOW. It could be different from what it was a month ago, and it will be different in a month from now. You will gain experience what the team can do over time. That will give projections for cost and completion times. With good enough management of priorities and the value of the feature set it is possible to approach something attainable. Also, there must be openness to react and change the plan. Staffing changes will provide additional challenges but on the long run it is possible to gauge how the project is doing over how the team is doing in the project.

There might not be so much value at all doing estimates for variable short term work where experience will quickly tell what the 'event horizon' is because you only really care about the immediate results anyway.

This is still somewhat simplistic analysis because it does not fully appricient the complexities of understanding work, producing right results, dealing with feedback and inspection. Building the right thing is still the most important goal and measuring that is very esoteric and based on things that are hard to measure. Many teams can call things done and can appear to make progress but what exactly are they producing and how? Sometimes you see those high profile failures that leaves you puzzled - obviously it was considered done, and all the rest, but it just did not work. Obviously the estimates were wrong, even when budget goals or time lines were met.

What is Product Design?

As a programmer, how do you answer that question? What is Product Design? Not oddly enough, people have a wide variety of opinions what really is product design. Ask a product manager and they think they are designing, ask UI designers and they think they are designing, ask a programmer and you get the same answer.

I came across these two posts about the topic:

• Web Design is Product Design
• Programming is Product Design

One is asserting that web designers that draw pretty pictures are really not doing the full round trip in web design. The other, which is a response, argues that programmers who do not do CSS and graphical design are not designing the whole thing either.

Both would be right, but the argument is just pointing to a dysfunction in typical design roles. There are so many aspects to design that people can't often do them all. However, if you are looking for some kind of ultimate solution, you want a virtuoso who can do it all. At the same time, it is probably not too much to ask  that people actually cross different disciplines. Often, that is better than mastery of programming alone, for example.

It is fine if a web designer draws images. It's a bit like making a rough sketch before the actual work starts, just get some idea about the web site. However, I would argue that there is still a big gap between that and actual design that is sufficient. Mastery of HTML and CSS should be required from web designers. And more than that, a real understanding of functionality and usability. This is the kind of middle ground that is very important but it is left in the no mans land, and that's a big gap in deed.

Programmers should know about HTML and CSS. Programmers can be a great asset in organizing and helping design here. Programmers are usually very particular about the aesthetics of organization, rules, practices. Programmers should know about usability, and how software translates to user experience. This is not important only because it makes user's life easier but it also affects how software is designed, and therefore it makes programmer's life easier.

There is a nice symbiotic relationship that can be created here where web designers, functional designers, and programmers can cross disciplines and interact in a positive way. It is easier said than done, of course. I have long argued that web designers should be integrated to the programming teams as full fledged members. In agile terminology, it is all matter of definition of "done". How can you really separate web design from programming, when all of that is in the cross roads that makes software great, or not?