Drill Down of Company Operation from Basic Business Requirements

As with any company there must be a relationship between the basic business requirements and the operation of the business .

The most basic requirement of any business is ' capital productivity ' . Capital productivity is the maintenance and increase of the capital value of a company . When capital is invested in a company it is transformed into assets . These assets can be of many forms . Conceptually they are divided into tangible assets - buildings , equipment etc. - and intangible - people etc. . Within a company that develops software it is very important that the software be treated as an asset . Often it isn't .

Assets must have ' asset calculations ' applied to them . These determine

1. the cost of the asset - how much it costs to develop the code - the initial investment .
2. the loss of value of the asset - the devaluation as expressed as a loss of value over a period of time - usually over a year .
3. the expenditure required to maintain and increase the value of the asset . In software terms this is maintenance and update costs .

Assets are very curious things . They are items that cost up front , can generate income and can be sold on and in some forms they can walk out of the door .

What minimises the costs in the industry as a whole - minimises the amount of unnecessary code development - minimises the cost of using the components - maximises the value of those components that are developed . The best designed code is code that requires the least amount effort expended overall . The software industry is like the motor car industry of the 1920's or earlier . Then there were many car parts that had to be fitted by the use of extra tooling - such as the use of lathes . Subsequently the car industry manufactured parts such that they could be put directly in without further work . IE. the amount of overall effort was minimised .

Components should be developed as assets but marketed as commodities . Not the other way around .

The fact is that a lot of business people do not translate the business side into the engineering side - they treat the engineering side as an unknown . Likewise on the engineering - programming - side - they often don't fully understand the business side . As a result of this disjuncture software development is often undertaken , within the business , without full consideration of the business requirements . Good business translated into good engineering produces good engineering which translates into good business .

As with anything in life code development is a matter of balance - of optimising - rather than minimising . As such :-

1. it is very important that the initial development produce optimised code . Minimal development cost - ' quick and nasty ' - code actually has large down stream - maintenance and update - costs . Consequentially it has low asset value .
2. it is very important that the life time of the code be maximised . If code has to be constantly replaced it has minimal lifetime and hence minimal value . The best bad example of this is customised application engineering companies . These usually redevelop large amounts of their code for each end user contract . As such their code has very limited lifetime and , hence , very limited asset value .
3. it is very important that the market reach of the code be maximised . This is carried out by generalising the design of the code - maximising the locus of validity of the code .
4. it is very important that the expenditure to maintain , support and update the code be minimised . This is carried out by designing the code such that bugs are minimised , contained and easily found . By designing the code such that it is easy and quick to use . By designing the code such that it can be easily expanded and evolved .

A project is designed well if good design principles - good design philosophy - is applied to it .

Componentisation is very important but components have to be designed on the following principles :-

1. the total amount of code developed has to be minimised . Actions which work against this are :-
   1. simplistic - noddy - code . Many layers of simplistic code does not optimise - minimise overall - the amount of code - it just leads to overly complicated code .
   2. big blob - directly overly complicated code - requires a lot of code to deal with the complexity .
   3. code which requires much support code . This often occurs where parent components - such as a multi media play engine - require child components - such as the codecs - to each have large amounts of common code - such as buffer management - duplicated in each of the components . At it's worst components can be designed such that they are not self contained and , as such , require a lot of support code - a lot of ' write arounds ' - in the components that they are connected to . This is a situation that is half way from a well compontised system to a big blog .
      
   the ways to optimise - minimise overall - the amount of code are :-
   1. to choose the best structure for the code . The structure has to be thought out . It is not a matter of just bunging in a solution . There are different ways of solving a problem , some are better than others . It's a matter of examining all the ways and choosing the best way . Often , though , peoples personalities - egos - and politics get in the way .
      A common way that this goes astray is where RTOS's are used - often there is far greater use of mutex's and far too little use of mailboxes - event messaging - than there should be . Principles of self containment must be applied :-
      1. a component must be totally responsible for all data and operations within it's domain - there must be no visibility of the component's domain provided to other components .
      2. all actions within the component's domain must be performed within the component's task .
   2. to divide the areas of the program into components . It is very important that the areas - hence components - are properly identified and demarcated - that there is no fussiness .
   3. the structure - and hence the components - must have a clear 1 to 1 relationship to the physicality - the reality - of what is trying to be achieved . The fact is that software is actually a very physical thing - to try to portray it as anything other than that is actually self deluding and just adds to the complexity of the code and makes it harder to deal with .
   4. to common the code . This is undertaken by :-
      1. within components identifying common operations and commoning this code into functions .
      2. in between components identifying common operations and commoning these into parent components .
      3. putting general functionality into utility functions within utility components .
      The common area where projects go wrong is the lack of rationalising of the project . Projects have to be thought out rationally , thoroughly and much commoning of code must be undertaken .
2. to minimise maintenance costs . This is undertaken by :-
   1. minimising the likelihood of bugs occurring . This is done by sensible code design - maximising the locus of validity of the code . If the code is designed on the basis of rules - if exceptions are not created - then opportunities for bugs are not created .
   2. designing the code such that it can be easily used without causing bugging conditions .
   3. designing the code such that bugs are localised in their effect .
   4. designing the code such that bugs are easily identified .
   5. sufficiently testing the code .
3. to minimise update costs . This is undertaken by :-
   1. ensuring that any expansions require minimum alterations to the existing code .
   2. ensuring that the code can be easily evolved .

Common to all aspects of good code design is good methodology . This includes good coding standards which includes using good naming conventions . Code has to be easy to copy , paste and change using the replace operation . It must be explicit in it's construction and layout and be well commented .