The Business of Creativity. 

There has always been an uneasy relationship between the artistic creative industries and large corporate companies and finance. There is a deep suspicion amongst the artists that the corporation will not only sell their products but try to influence and control the creative process.creative control  This was always the (quite legitimate ) worry for musicians signing to one of the large record companies.In engineering there has been in recent years the scaling back of engineering management layers in order to better control the engineering product or engineering schedule at source. Historically engineering management has been essential, to protect or defend the engineers dilemmas,explaining in management speak the problems and difficulties regarding the design and production of complex products.In large corporations the need to save money has meant cutting out the middle management but in reality it means the creatives must also take up the role of administration and explanation.

Complexity and Explanation.

The products are now so complex that the creatives need more time than ever to analyse and problem solve. The schizophrenic behaviour required by fulfilling all roles is mentally debilitating & ultimately self defeating. Why ask the techies or creatives to do cost, budget, schedule and contract management as part of their daily routines when business specialists could be targeted to manage the complexity these tasks. Where is the respect and understanding between the business and creative disciplines?.
Its getting difficult to attract highly skilled engineers into certain specialist areas of industry, by adding tasks (such as costings scheduling administration) it can only dilute the quality of contribution of the engineers employed in specialised roles. The old methods such as  no.of lines of code and power point slides cannot now with explanations of complex interdependencies. Increasingly we need some kind of visualisations or graphics to show project timelines and the evolution of development to keep the dialogues going (some time for years)between teams on a project.

Institutions and Added Value 

In recent times some corporate record companies have failed, due to musicians & artists selling their music directly on the internet EMI. The record companies have not been able to let the musicians identify any "added value" from the management of their creative talent.It is not such a large step to think that some time in the future engineering/science creatives may be able to sell their talent directly to projects funded by private or microfunded Microfinance intiatives and travel between projects without the need to be employed by the current major industry players. If large corporate organisations want to remain relevant to these industries they must demonstrate added value to the engineers & scientists that they employ. They can do this by providing infrastructure and stability for multiple & transient teams and disciplines to work together.

Joy in Numbers

One of the main benefits the larger employer can exploit is the sheer number of employees they employ. The melting pot of talented staff is one of the main reasons stay working in these large companies in spite of lower wages,poor quality working environments and substandard management techniques and expertise. Allowing networking and collaboration possibilities and a better environment to support collaboration and development activities will ensure better engagement and belonging. A larger employer may have available funds to provide a good facility to enable innovation and collaboration, this environment when provided thoughtfully, this can affect the quality of products,innovation and production creative environments Creative communities do not always appear where they are wanted - they sometimes just appear.  For instance it would be hard to get a group of any painters or musicians to live/work anywhere they didn't want to or that was detrimental to their work. What most creative people want in science art or otherwise is a chance talk to other creative people about their work and the opportunity to create stuff.

On the shoulders of Pragmatists.

On the shoulders of Pragmatists.

I sat through a very long presentation today on how we were going to save money on future projects. Its always interesting to see that the team which will be cut back is the team that was not in the room when the budgets were being discussed. The reasons the saving will be achieved were a bit woolly needless to say that software should be trimmed back and other more prominent depts should get a bit more.  The savings are thought to be made around the rather tricky subject of autocoding.  I would have been happier if the autocoding case was put forward by software peeps but it was not. In my experience autocoding is best used by the people at the coalface who know which functions it will help and where not to take any risks, this takes quite a bit of experience. Autocoding like automated phone operators can replicate aspects of non-changeable functions but like the automated telephone answering system,but if the question doesn't fit you can get passed round an endless loop of A B or C when you really want to "speak to an advisor".

Modularise and shut your eyes.

Later in the day there was another interesting comment when trying to set up a common working area with some of our sub-cos there was strong resistance to the working together philosophy, very experienced engineers (not software ones) were explaining to me it is better to modularise software and let the teams deliver a stand alone package and reduce any collaborative activities. I appreciate the thought but if a product we are working with is not created in  a multiple contributor and protected core design, and is a product designed to be coded and configured in-house there will be problems. Some product in the industry are conceived and written well before the "thin-prime" spectre haunted the  corridors. Modularisation is an important design consideration but is of course not an excuse for not collaborating communicating with the project stakeholders.

See no evil hear no evil ( "simplicity" = "complexity")

It is strange that with the increasing software complexity and the bafflement of our own experienced engineers in our the ever challenging environment, increasingly personnel from other areas of discipline are taking it on themselves to explain to us that things are now simpler in the software world (and therefore cheaper) than we thought. The worrying thing is that the only resistance I can see to this is a sharp raising of the eyebrows by my colleagues in meetings, but these people are so knocked by the current economic climate the emperor will be parading around in his blissfully ignorant nudity for some time to come. Software engineers need to become excellent in explaining complex issues to another discipline in particular to Project Management.

No Respect for a new discipline

I have frequently heard software referred to as the "dark arts". This is not good for a variety of reasons but being referred to as voldemore or HP himself is not helping the collaboration & respect issues between disciplines. 
It is official there is no respect for software in the more elevated parts of the engineering industry, perhaps it is because it is still a relatively new discipline. Software though over the last 15-20 years has learned to be a bit more humble than some engineering disciplines. It has taken on the nightmare of incremental deliveries and being extremely pleasant to the customer without "people-skills" being a key software engineer quality, software folk have had to respond to complexity,financial accountability and the possibility of having got things slightly or very wrong much earlier in the development phase- when other people are still eating the bid-win celebration canapes. We now know by bitter experience if the misinterpretation of  key requirements can be addressed early on by demonstration, simulation, or modelling it can save huge amounts of recoding and misunderstanding later on in the project, when everything is interdependent and difficult to update and modify.

Raising The Game

One resistant problem is system folk and other disciplines continue in the waterfall V development not understanding the shifting sands of the software and data development, therefore the tools and environments provided by project will not be supportive for this flexibility. It is not possible to use a document configuration system to cope with configuration control in a software and data development environment they will need special (probably expensive to maintain) tools. It is the job of the SW dept manager to make sure the costs for these and risk offsets are well understood by the rest of the company. If we can maintain a humble approach in software it will serve us better to be able to question the large" fix-it-all" tool. It is important to be able to question the sanity of signing up to any tool/ model that is proposed as replacement for the need to talk to other disciplines about their worries over timing and data format issues. As we pass our data from the central database to the sw datasmiths its true we can change formats many times just to cope with the various environments. It is not possible to get all the disciplines to align on one environment but the excellence required to tidy up the interfaces between environments should be a key focus for the community.


In short experienced (read aging ,tired & worn out) software people its been a tough decade. Brush yourself down, put a bow in your hair (metaphorically or otherwise) and stand tall. All the lessons that have been learned in the last decade (and before) are highly valuable to engineering and technology industries, even if we dont "feel the love".  if software teams can bring with good humility, our mastering,understanding and management of complexity,then include the excellence of good interfaces between disciplines, we will set the bar higher. We will be able to play our part in leading the technological and scientific communities forward to help with the explanations of increasingly complicated tasks for both the current and the next generation of engineers and scientists.

When things go wrong.

 

The SpaceX rocket didn't launch yesterday.  extract from wired "Once the limit was hit, launch software took over and aborted the liftoff." In a post abort press conference, SpaceX president Gwynne Shotwell said "the problem looked like an actual issue with the engine and was not one of the sensor or software issues that had led to delays in the schedule earlier this year during simulations."

"We can not blame the software guys for this one," Shotwell noted.

From a software perspective this statement was a bit disappointing for some reason there was a feeling amongst the software community that perhaps new companies with more modern approaches to business might have managed also to have a more honest view  about the software & data community in the space industry.

The spacecraft in its physical form must be reflected in a data shape that absolutely resembles every feature and status that is available on the spacecraft. During and after launch the only way to communicate with the spacecraft is by a limited number of datapackets which must helpfully contain, or the possibility to contain every possible combination of commands and statuses available to the spacecraft. 

This spacecraft dataset is produced by many different discipline teams working on the project. In fact almost every team will produce some kind of data in spreadsheets,file or document format. This dataset is then combined with processes to manipulate store and perform calculations, there are many software components and applications to manipulate this data and many data format changes to pass information between teams. 

For the final operation and integration of the processes and datasets to work teams must be highly communicative and interactive. If there is any discord among teams it will be reflected in the data and software integration and operation. Where there is a team that is not trusted there will more checking of values. Where there is a team that tries to do the least possible there will be add-ons made to other unfortunate teams that have had to pick up this "dropped off" functionality. Where one team is quiet or timid they may have found it difficult to  give feedback to another more arrogant teams design approach. Any imbalance and disrespect between disciplines will generally be to the detriment to the overall design or become a risk to mission success.

If there is a problem with a spacecraft launch or delivery today, you can guarantee it will probably be software or data related problem. This is not because software and data teams are a few small guys in a room with some pizzas that have lost track of time, its because every team on a project is generating data,information and processes which complete the   spacecrafts final data image. It is this error prone data imprint of the spacecraft that closely reflects our imperfect selves.

My Personal Genghis Khan 

Just a quick rant about the lack of processes, or the removal of processes in the cause of cost saving activities. Over the years and in different companies, I have had experience of several figures who have arrived on a project and made life hell for people one way or another.

Each time this happens I wonder if I could do something to avoid us being" damned to repeat history". 

Know yourself.

In the Space Industry projects tend to last a long time and senior management staff turnover is usually the fastest. Middle management tend to stay longer usually at least 25 years. From an engineering perspective sometimes it seems senior management make decisions about things they don't really understand, as they dont like consulting the technical teams who can seem unhelpful,arrogant or eccentric. They see their role to take decisions and consultation as adding unnecessary delays and complications.

Technical teams often do not appear to see their role to advise senior management they sometimes prefer to be told what to do or to avoid confrontation. On both sides this can be a severe abdication of responsibility. When teams have a weak team leader it can leave a team with increasingly impossible tasks,cancelled holidays and no possibility of success. Quite often if a bad culture is recognised, unless you have reasonable authority or decision making powers it probably is better, where possible, to leave the project.

Mental Health - a touch of madness
I have noticed over the years that there have been some managers (sometimes senior engineers) that really have a touch of madness, this seems only to be obvious to all parties only once they have left, by which time most of the dept have left or gone off sick with stress and all employee diversity is removed ie At this point the only people left may be a small set of hardened contractors that have weathered somewhere extreme like Afghanistan - well you get the picture. Quite often your personal Genghis is very charming and highly intelligent and you will not win if you take them on head to head. As I said before if you recognise a bad culture and you havent been able to get reasonable seniority it is time to start to update your CV.

The Last bus home
So what can one do to avoid this happening again to confront ones own personal Genghis Khan?,.
My feeling firstly is probably there should be a mental health check. Maybe easier for HR PR to call it health check but Im guessing, asking a few questions on a regular basis to all project team members could get a project mental health temperature reading.
The second one is that cost saving should not mean leaving one person to make all the decisions without any support. Roles and responsibilities collapse to save cost but the distribution of the work is not fairly distributed and it appears some people are kept permanently too busy to keep them from becoming effective decision makers. Strategies that we are happy to talk about in the abstract, like game theory or Fault Investigation Diagnosis and Recovery are completely forgotten when the space industry comes to people management strategies. It may be necessary to really start the conversation going where we demonstrate the desired patterns of behaviour for project teams. If we can manage to recognise good patterns of behaviour we may have a chance to replicate desirable artificial intelligence algorithms. Ignoring the crazy behaviour that happens in human stressful situations only stores up problems for us when really working in space, where when we find ourself abandoned by our project team, or cornered by our personal Genghis Khan, we cant just get the last bus home.