The View from Stuttgart: On Sloth

I am basically and fundamentally a lazy person. This is deemed by colleagues as a mysterious self-image to have, especially when I call them at 2200 or 0600 but is nevertheless true, (Just ask my wife). This disposition led me to coin the phase, “Sloth is the father of Efficiency” actually it was in Russian (where it rhymes much better) Ленивость Отец Эффективности - Lenivost‘ Otec Effektivnosti. The idea behind the phrase was born out of “Necessity is the mother of invention”, which came from the Latin, "Mater artium necessitas," which first appears in the early 1500s in England and is my main reason for learning languages. The primary necessity being, gaining an ability to engage the opposite sex from around the world in conversation (you needn’t ask my wife about that, trust me).

The initial target audience for the phrase was groups of russian architects and construction engineers and I was at the time running projects fitting out office blocks in the collapsing chaotic post-soviet space for merchant- banks and well-to-do Russian companies who wanted to emulate their Western counterparts. To this audience the motto was well received – they had enough to be worrying about so high-end flooring, partitioning, desking systems, expensive imported tools and a company that would take over its design, shipping and installation was well received. In one western bank’s offices in Moscow I witnessed the tax-police entering the Coca-cola head-quarters. Sounds undramatic but tax inspectors at that time were usually accompanied by special-forces who absailed down the side of the building and smashed through the windows, so clients typically really did have a lot of other issues to be concerned with. It was also a solution that even inexperienced, slightly-intoxicated people could cope with. So with one or two western experts around we could easily out-compete on labour cost since other companies were flying in the majority of their installers in from the West or using local ex-pat contracting firms. Of course alcohol was strictly banned on site, but this was a crumbled Soviet Union and I won’t paint a picture that is completely inaccurate. Despite our best efforts to ensure sobriety I cannot say we were 100% successful in doing so. Health & Safety was also an issue. On one occassion I remember saying to a russian site-manager that he should block off a lift-shaft being worked on above because there were people working below. I got the answer “Don’t worry they are only “Churky”. Churky is the Russian equivalent of ”Nigger” and used to describe people, typically from the Caucases.

Although it was incredibly lucrative from 1994-1999, in 1998 Russia defaulted and the Rouble went from 7 to the dollar to 33 overnight. Moscow became a ghost town for quite a few months and I decided to go and do something which might bring in less money, but was more interesting, future oriented and with hopefully fewer people willing to put others life in danger for no good reason. This is all apparently a long-long way away from the businesses I have been involved in since 1999. And indeed in someways it really is. But there are also major similarities.

The notion of "sloth" (https://en.wikipedia.org/wiki/Sloth_%28deadly_sin%29) being the father of efficiency stayed with me. Though re-using the expression with young Russian software and calibration engineers during the setup of our operation there went down far less well, most of them being pretty efficient, damn talented as well as keen to separate themselves from the immediate soviet and post-soviet past it still somehow lies at the core of what I do as a as a consultant in software-engineering processes, developer and supplier of tools. In particular, the development and roll-out of tooling as a business exists purely to support the introduction of better processes which reduce effort and save money – or allow greater production for the same cost. If a new process or tooling doesn’t achieve this simple aim – then the best salesman in the world can sell it once, or, if you are really unlucky several times – but don’t expect the customer to come back for more!

I would probably be our ideal customer in some ways because of this inherent laziness. At home I am constantly on the look-out for ways to do the housework and gardening with the minimum amount of effort. My kitchen is regimented so that dish washing entails moving the minimum number of times between dishwasher and draw and I get rather upset when either the draw or dishwasher are inaccurately loaded. Drives my wife mad. When it comes to the garden it is enjoyable wondering around doing something which vaguely benefits the landscape in some way. I can even cope with digging holes and filling them back up again but when it comes to clipping hedges I want a good machine. And as for raking up the bits that are cut off – I’m waiting for someone to bring to market an autonomous raking up and shredding machine that will dump it all in the compost bin bringing tea or cold drinks at suitable intervals and a good Gin & Tonic at about 1800. In the meantime Juan, the gardner does that bit, but he’s lousy at Gin & Tonics. There is also some resistance from the CFO on that front since my time at home is apparently “free” as far as she is concerned. That makes the investment in any tool or process hard to justify. Whatever you do don’t look at things like this as being “free”. Nothing is “Free”. Ever. Especially my time. Hopefully your time is just as valuable.

I have heard clients many times thinking precisely like my wife. “Well… we’ve got these guys sitting around anyway, so if we haven’t got anything for them to do they might as well just build something which they know nothing about because we currently buy that from somebody who knows loads about that but charges us money for it.” A bit like asking me to paint the some random part of the house. I’ll take 2 weeks to do it as opposed to 2 days for a pro. And I am colour-blind. So there is a very high-risk that that lovely pink that was selected might end up being grey or lavender. So applying the wrong skill-set to the problem is not always helpful and can end up expensive instead of “free”. This isn’t just another pitch from just another consultant it’s a purely economic argument. Deciding what is core to your business, and what is not, is key. Developing processes and tools is usually not one of them. It is just Adam Smith’s pin factory writ large and with software-driven vehicles in place of pins. Construction companies construct buildings – going into the power-tools business does not make a lot of sense but in automotive it is quite usual for entire development environments and core process tools to be developed in-house. This is partly because of what we discussed a bit last week, that the rise of software in Automotive has been sudden and brutal and the existing tools and services providers, either for software or for automotive engineering have struggled to keep up, so OEMs and Tier 1s were forced to develop things for themselves and sometimes they actually did a damn good job.

Now here in the process consulting and tooling business sometimes we also hit a paradox. That is that we have a vast number (nevertheless inevitably an insufficient number,) of highly talented, motivated engineers and computer scientists. Guess what they love doing? That’s right. Writing code and engineering! That means in some cases we have to watch out that that the prime directive is still being fulfilled. These guys are sharp and typically if they think they have finished what they are supposed to do will find something more entertaining to be getting along with. In my early years in software engineering projects I can think of at least two occasions when members of my team were competing to do each others job better than the other whilst ignoring the main task at hand. And I’m pretty sure we are all familiar with the “NIH” phenomenon. Not Invented Here. That’s because among the best engineers are a lot of males, some with borderline Aspergers. That is not a slight either on male engineers or on people with Aspergers. Just a recognition of the fact that males with excellent engineering skills sometimes have a deficit in other areas just like anyone else. I am colourblind, forgetful and more or less fashion-free, but there are some redeeming qualities I just can’t quite remember them right now. One exceptionally talented developer had to spend some time on the help desk. The banality (to him ) of some of the users questions drove him insane, to the extent that we started to hear him screaming “Read the F**king manual!” to clients on the other end of the line. We had to sort that one out quite quickly. To underline the point SAP recently specifically hired people with Aspergers precisely for their qualities (https://www.tagesspiegel.de/wirtschaft/software-riese-auf-der-suche-nach-it-spezialisten-sap-stellt-hunderte-autisten-ein/8234972.html) and this I think is an increasing trend more generally. To recognise the diversity required to build the strongest teams means that those hard-nosed and evil corporations can actually make more money if they are more socially inclusive. Sounds a bit Utopian but it turns out to be true (see https://www.cnbc.com/2014/04/23/the-growing-case-for-diversity-as-a-profit-creator.html for example).

Two jokes come to mind about the peculiarities of Mathematicians and Engineers. Both were told to me by a pure mathematician on the one hand and an Engineering Phd on the other so I hope that will get me off the hook with anyone reading from either of those disciplines. The first is:

Q:“How do you tell the difference between a pure mathematician and an applied mathematician?”
A:”The applied mathematician is the one looking at YOUR shoes” (ie neither can handle eye-contact and the pure mathematician limits his gaze strictly to a circle where r=the length of his shoes in mm, whereas with the applied mathematian r stretches to the bottom of your ankles)

The second is:

One day a (male) engineer was crossing campus to meet his friend, another (male) engineer for lunch. Upon meeting at the rendez-vous his friend turned to him and said, “Nice bike! Where did you get that from, didn’t know you had one, I thought you’d be walking”
“Yeah.”, said the first engineer, “You wouldn’t believe what happened to me on the way over. There I was walking a long and this georgeous girl came past on me on this bike, turned around, dropped the bike, took all of her clothes off, dropped them on the floor and started writhing on the ground shouting ‘Take-me Take-me.”
“So I picked up the bike and here I am!”
“Good job!” Said the second engineer “The clothes would have never fit you”.

So to enable as much lazy time as possible (or should I say high levels of efficiency?) requires a high level of baseline work – that you can neglect and apparently save time/money in the short term – but be prepared for this to come back and bite you harder in the coming months and years in that case, right when you don’t expect it. You need to spend time looking for the right members of the team with the right skill sets – internally and externally. You need to plan and continuously improve processes to ensure you are not falling behind industry standards, which will at some time make you less competitive and you also need to be aware of the implications of new technologies which have an impact on the speed of development, reliability and safety of the code produced and be able to conduct a cost-benefit analysis of its adoption, skipping or later implementation.

As things stand in automotive we already have a huge base of code, which is increasing more or less exponentially and we need to focus like a laser on making sure that new code is developed faster, produced as efficiently as possible, is traceable to original high level requirements and above all testable, safe and unable to be corrupted during operation or updates. At the same time we have a huge body of code which is tested to death, proven in millions of vehicles but based on technology which is sometimes decades old. This may not be a problem in and of itself but when we start thinking about new hardware which will require this code to be reworked anyhow, integration with new requirements to bring ADAS and autonomous features to market and outside of the safety critical systems themselves, a rapidly evolving infrastructure for on-the-fly over-the-air updates for body, driver information and multimedia applications, this code base transforms itself from being something we can take “for free” from the previous platform to a technical debt that we need desperately to reduce to the minimum and avoid re-introducing in the next platform generation.

So that's the ultimate paradox and irony I guess. If you want to have the time to be lazy or the fruits of efficiency sometimes you need to put a lot of effort in up-front.

Thanks again if you made it this far and have a great weekend!

The contents of this post are those of Mr David Bailey and do not necessarily represent the views of ETAS GmbH or Robert Bosch GmbH who are his employer.