Creating an extra high productivity & extra high quality SW development team

Background

We have actually known for a long time much of the concepts and theory of good software development. The journey of 50 year of computing has gradually led us into the point where we understand.

The result of this is model driven process that ends up to a 3-tier application implementation. The layers are: Application layer, Domain layer and Persistence layer. The key element in this approach is the unidirectional association between the application and the domain layer. Here the application layer is strongly associated with domain layer but the domain layer has no references out of it at all! The development process should start with abstract domain modeling. This phase won’t take more than 10 working days in average of a team to build. The development starts from just implementing this model. Then it continues incrementally with design and implementation of the application GUI and workflows. As the work proceeds the details are also added to domain layer that started with skeleton model. The experience from several projects is that the number of classes increases very little but addition of attributes and behavior is of course substantial.

Great opportunity for a top high quality & high productivity team

Currently most of the development of operational software for companies is done based on very old and proven bad paradigms. In practice majority of development is done with a waterfall approach. This is bound from different directions like, wrong idea of the nature of the work, planning and working tradition, buying, selling and agreement traditions. This all lead to situation were a carefully selected team of skilful professionals would have an outstanding advantage in competing on the arena.

The structure and the working process have been proposed and even used many time in the past. I will assembly here ideas from Frederick Brooks: Mythical Man-Mont, Grady Booch: Object Solution, Ken Schwaber & Mike Beedle:  Agile Software Development with Scrum and Kent Beck: XP.

The good principles and best practices for such team could be added up as follows:

  • Small team with member each high professional skills
  • A Scrum-like working team yet somewhat different duties and responsibilities between team members. One could call it “surgical team” like Brooks did. In software the “surgeon” would be call chief programmer & architect.
  • There could be two teams. One for domain & total architecture and another for GUI & work flow control details. The interests of these teams are clearly more loosely connect than inside these teams.
  • The working process should start with clearly separated time boxed abstract domain modeling. Then the implementation process should start with generating the implementing code from this abstract model as starting point and guide lines for the incremental and iterative development work.
  • Professional skills tend to be badly underestimated. Somehow in IT-field the dominating assumption has been (as perhaps is still) that most of software development is routine work, which one can do with short introduction to work. The truth is complete opposite of this! The software implementation is difficult design work from modeling until the last line of coding. It is mostly problem solving and successful people have both good skill and enough routine work behind them to be good at it.The ideal small team could consist of following roles:
    • Chief domain developer. This fellow is the “surgeon”. He has the main responsibility of the overall success.
    • Domain co-developers (1 – 3). These as the assistants of the chief developer. The domain developers discuss and make the key design decision together. One of these is the deputy chief developer.
    • Application developer who designs and implements the work flow control
    • GUI designer
    • Case dependent additional roles
  • The team is really functional after a few ramp-up projects as each member learns to fit and function in this particularly team. To replays any team member requires a fully professional candidate and a learning period with assistance of the leaving member or the rest of the team.
  • One open question (that I cannot provide an answer now) is whether such teams should practice their performance  in advance outside any customer projects.

Really good customer is a must

All this things doesn’t work without the final link in the chain. This is the buyer, the one that the whole thing is done for and the one that should be the most interested in the result.

Participating in such a process require real interest and committing to the process. This means that the organization appoints the most knowledgeable key people in the project and at least some of those fulltime and that the management of the company is actively participating in the process.

In an agile development process very important decisions must be made all along the process. Actually the development of an operation management system is always at the same time a huge opportunity and a steep learning process for the whole organization.

Choosing the customer (at least at early state of working this way) is actually more crucial than creating the best possible team.

Paradigms and Object Paradigm in particularly with quote from Grady Booch

The concept of paradigm is a tricky one. To characterize this in some way we can describe paradigm as a outmost explanatory framework or mechanism of modeling a complex thing. (see: http://en.wikipedia.org/wiki/Paradigm).

A paradigm offers building blocks to create a model of complex part of reality. These building block are in a sense fundamental to all models ( you could call them explanations as well) that are base on that paradigm.

The paradigms for same aspect are mutually exclusive. Let’s take a concrete example. If you want to create a 3-dimensional model of houses, you can us as you building material for example: Lego bricks, matchboxes or carbon. With each of these materials you can achieve good results but the working techniques differ and of course there are differences in the end results too. Now these three materials – the building blocks – represents here the paradigms. The first (and I consider this most important) result of this consideration is that is impossible to mix paradigms. Either you work with Legos or matchboxes but there no way of mixing these materials. This is universally true with different paradigms explaining the same aspect of the same part of reality.

The article in Wiki also mentions both paradigm shift and paradigm paralysis. It seems that the used paradigms are changed from time to time to more accurate or explaining ones. For instance people hade from the days of antique Greece a very commonly adopted paradigm of solar system. People believed that it is geocentric.  When time passed and people learned more about the universe they realized that their understanding of Solar system was wrong and they had to do a paradigm shift to heliocentric. This shift proved to be a difficult one at least for part of people (at least around Catholic Church). This ended in a paradigm paralysis. The reasons behind this were various and so were the explanations and excuses.

Now let’s consider the object paradigm. The paradigm shift happened from procedural paradigm. The key difference between the paradigms here is in how they describe model’s behavior. The older paradigm has a simple way of slicing the behavior in time and end up with time flow of events as the object paradigm describes the behavior as collaboration of named objects and their separated responsibilities. These ways of describing behavior are mutually exclusive. If you explain the behavior as flow of events there is no point in doing that all over again with collaborative object and their distribution of work. If this would be done one of the models would be completely redundant and unnecessary or even confusing!

I think that most of business application development today are done with OO-languages and most of the design is done in procedural way. My question is how far we are in the paradigm shift and how bad is the paradigm paralysis with procedural approach? The fact is that application development with object paradigm is from 2 to 10 time as effective as with the previous one! In the next post I will elaborate on this and start it with a quote – part of epilogue from Grady  Booch’s Object Solutions book.

  • Software development is difficult
  • Object-oriented technology helps

Is object-oriented technology mature enough upon which to build indus­trial-strength systems? Absolutely. Does this technology scale? Indeed. Is it the sole technology worth considering? No way. Is there some better technology we should be using in the future? Possibly, but I am clueless as to what that might be.

It is dangerous to make predictions, especially in a discipline that changes so rapidly, but one thing I can say with confidence is that I have seen the future, and it is object-oriented.

This was written around 1995. At that time the OO boom was at it’s heights and we all though that transition from procedural would be graduate, smooth and strait forward. It proved to be more difficult and there were a lot of forces against it. There were (some still are) the mighty stakeholder of procedural legacy.  The new concept proved to bee more difficult for many people than we thought.  Anyhow everything here hold today! of course we have learned something in 15 years and we can do things more efficiently today but the bases is here, solid and holds! The software that I am working with can and should all be implemented with OO.

Airline business (Business area models:)

Business area models:  Airline business

Here is now my second business area abstract domain model. My second target is Route Airline business. I have been working in Finnair about ten years, so I know the business and the model by myself very well.

The target scope have been narrowed a bit from general airline. This model concentrates on a typical flag carrier base operation: route flights. All these transportation core models contains a pattern; a pair of route design and implementation aspects:  Route, RouteFlight classes for design and Flight for real event.

The largest business cycle – or pulse- is a period or a season like spring, summer, autumn.   These periods are planned and coordinated as one unit. So my example is Finnair and its route can be for example Helsinki – London. When this is decided then the airline has to decide the weekly operating days and the plain type out of the fleet. When this is done then the airline have to negotiate the gate time slots. When this is done the plan for a periods route operation is ready.

The models class RouteFlight is on description object of a single repeating flight. The real flight event can then be generated for a given period from these objects.

The basic collaboration are very straight forward. Here is one of those: buying a ticket and reserving a seat:

These diagrams can be found in StartUML form at:  http://personal.inet.fi/cool/jukkatamminen/OOstaf/Airline/ RouteFlightCompany.uml

Just upload and open with StarUML.