Mentees, not manatees

I was recently fortunate enough to find myself invited to a webinar/workshop where I was introduced as an “expert” and mentor. Now I’m fairly happy for people to call me whatever they like, so long as it’s not too rude, but expert is not something I have ever felt comfortable with. When it comes to the niche world of BIM there are, in my honest opinion, rather too many “experts” around. After all, not everyone can be an expert in their field, surely? Where are all the “enthusiastic journeymen” or even “keen amateurs”? In fact, the term is so overused as to be in danger of becoming rather meaningless. It has become like the “Celtic arm ring” tattoo equivalent, that looked great in Bali in the 90’s when no one else had one, but is so mainstream these days that it can be more of a talking point NOT to have a tattoo.

Arm ring tattoos: so passé.

So if we are not to introduce all knowledgeable BIM peeps as “experts”, then what should we be introducing them as instead? Well, here is a suggestion; although it is only a suggestion. How about we just do away with all the guff about how “Mr So-and-so was the first person in the world to export an NWC file”, or “Ms Blah-de-blah is frequently invited to perform parlour tricks to government ministers” and let the audience judge the value of the content for themselves? Why? Because it is my considered opinion, having sat through a few of these things in my time, that the true “experts” of any given BIM situation spend far too much of their time attempting to unravel the Gordian Knots they frequently confront on their projects that they simply haven’t the time to fanny about with putting fancy Powerpoint slideshows together. You are as likely to find genuine expertise in the audience at such events as on the stage talking about it.

So back to where I started with this. A webinar thing. What with the COVID-19 apocalypse, the industry, which previously comprised of a calendar filled with copious networking events, seminars, lectures and summits, culminating in the “Burning Man festival of BIM” that was Autodesk University with its annual pilgrimage to Las Vegas, was completely wiped out. If there was any silver lining to this great, black cloud of the pandemic, it is that far fewer people have been subjected to the merry-go-round of unrepresentative award ceremonies, snake oil salesmen soapbox events and theory lacking in practical application that has been a feature of the growth of BIM. Many senior IT/CAD/BIM/digital whatever saleswankers have been prevented from attending their annual get togethers on the company Dime. And, guess what? Has the push for BIM upskilling and usage fallen behind globally by a whole year? I guess we will know for certain as 2021 progresses, but something tells me that this whole experience, as painful as it has been for so many people due to furloughs and staff cuts, it should have become abundantly clear that the parasitical relationship between software vendors via the preferred vectors of IT/CAD/BIM/digital departments, is not only unhealthy but entirely superfluous to meaningful progression and uptake of BIM throughout the AECO industry.

Something we can all do though, and something that does add value and meaning, both to teacher and pupil, is mentoring. If all of those “enthusiastic journeymen” and “keen amateurs” were to each find a suitable BIM professional mentor to take them under their wing, and those mentees were to go on and do the same once suitably experienced, the whole upskilling and knowledge cock-block that is the most frequent accusation foisted upon BIM advocates as the reason why “Design Department A doesn’t do BIM” would be progressively overcome.

But do remember one thing; it’s mentees, not manatees.

IT Managers: How not to support BIM

During the early stages of a large infrastructure project I was involved in circa 2014, it was decided to deploy Revit Server to support the team of 50+ architects and engineers developing the models for the project. As the company’s offices were split between 2 buildings in the same location, a Revit Server host was located in the main server room in the head office while an accelerator was deployed in the main project office.

This was necessary as there were teams working on the models located in both offices, and the trunk line connecting the two was only 100Mbps, which doesn’t support the traffic that would be flowing on the project, and corrupt Revit files would have been a huge risk. An order was placed to upgrade the trunk line to 1Gbps, but it would take a couple of months so the Revit server solution was essential.

Just getting approval for Revit Server was blocked by Global IT as they favoured the use of ProjectWise that was being rolled out across the business, and they tried to convince us that splitting the models into tiny worksets which individuals could check in and out of ProjectWise would be the best solution. BIM Managers from 3 countries were flown to the UK to be browbeaten into accepting this disastrous workflow, they even brought in one half of the team that came up with the BIM Wedge (it was his idea) to argue with us that using ProjectWise like this was a great idea. The reality, as ever, was that politics were at work and several of the IT bods had hung their careers on getting ProjectWise enforced across the company, and they strongly asserted their authority to stop us from using Revit Server, that they considered a threat to their positions as technical leaders.

Which one do you think it was?

On returning back to the other side of the world, I pleaded our case for Revit Server with the PM, and he escalated up to the regional CEO, who told the Global CEO in no uncertain terms that we were having Revit Server installed, whether the IT goons agreed or not. We won.

Anyway, after a few months of project operations, with multiple models being worked on by the team, we arrived one morning and nobody could access the models, the Revit Accelerator wasn’t responding. The local IT guys, who were not the sharpest bunch reported that there had been a power failure in the server room at the project office, and our server had abruptly stopped, corrupting all the files on the server. “What about the UPS?” I asked the IT guy, he said it had done its job and kept the server running for an extra 30 minutes. “And you were not able to access the server and shut it down remotely after getting the alert from the UPS?” I asked. “Well no, we bought cheap UPSs which didn’t send a power failure notification to the sysadmin”.

Yes Colin, they really are that dumb

This was bad enough, but the next cock up was a classic. The Revit Server installation was on a dedicated PC, and during routine checks the IT guys found that the hard drive was getting full, so had a look at the file system and deleted the folder with the most data, our Revit Server model store… It was a cock up of epic proportions, thankfully we were able to restore the models from local copies on people’s hard drives, otherwise we would have been screwed as we later found out they were not routinely backing up the server.

A lesson learnt, don’t trust IT people to do their job, they often don’t.

Autodesk are taking the piss

One of the most frustrating things about working with BIM tools is how pathetically bad they are, especially tools from Autodesk. Take Revit for example, it was the love child of an old, but smart, for its time, architectural tool called Pro Reflex which had its roots in the 1980s, and parametric mechanical CAD with its constraints and relationships. Its developers maintain that there is no Pro Reflex code in Revit, despite taking the source code with them when they left PTC to establish the Charles River Software, later renamed Revit Technology Corporation.

The guy who sold Pro Reflex to PTC, and therefore knows what he’s talking about, disputes the Revit developers’ claim that no code carried over into Revit, and has documented proof that there are definitely traces of 1980’s Pro Reflex code and design in Autodesk’s flagship BIM tool.

Whatever the merits of both of these claims, the fact is that as a parametric mechanical CAD tool, it is primitive and slow when compared to the modern ACIS 3D kernel from Spatial or Siemens’ Parasolid engine. And as an architectural tool, it does not allow architects to develop the buildings they want to design without resorting to developing special tools to make Revit do what they have asked Autodesk to make it do, but they have refused to spend any money on it. This, and price gouging on licenses, led to the Letter to Autodesk from prominent UK architects demanding action from Andrew Anagnost, Autodesk’s CEO, and covered in detail by Martyn Day in AEC Magazine. Things have got so bad that HOK, who are a Revit house and BIM pioneers, abandoned their Enterprise Agreement with Autodesk and are evaluating alternatives to replace Revit.

Those of us that work in large firms know how hard Autodesk are squeezing the balls of their EBA customers, the price of a usage token has risen over 70% in the past 3 years to more than 1.10 USD (Revit is 6 tokens a day), which has focussed the minds of CFOs and COOs in the tier 1 companies, many of which are formulating strategies to teach Autodesk a lesson. Autodesk University meetings will be very frosty this year.

Navisworks is another Autodesk product not developed in-house, but by a company in Sheffield, UK called Lightworks, that developed Navisworks to allow 3D models from multiple incompatible vendors to be combined in a single application. It was acquired by Autodesk in 2007, and has been a cash-cow ever since, receiving minimal updates and new features. Another example of Autodesk taking the piss. iConstruct wouldn’t exist if they weren’t taking the piss out of their customers, and remember that Navisworks Manage was one of the most expensive tools they sold.

But my biggest beef with Autodesk is that they have all these tools and products, and rather than making sure that they are able to be used collaboratively as a priority, few products are able to be used together except on a very basic and limited way. Revit’s monumentally stupid coordinates system for example is the cause or more lost unproductive hours than just about any feature on any piece of professional software.

Revit’s coordinate system will take it’s toll on almost every project, no matter how well you craft the execution plan or provide templates and strict instructions on how to link models together. On a recent project, the architect created his initial model, from which all other models in multiple applications (Revit, Plant3D, Civil3D and Bentley tools) took reference for the location of the model. A couple of months into the project, the architect decided to lower his his model by roughly 300m as they fucked up the original coordinates. As a consequence, chaos ensued and many many manhours were spent accommodating the fuckup by the architect, in some apps this meant starting again from scratch.

Autodesk’s cloud BIM collaboration platform is not much better. Trying to get models uploaded has brought document controllers to tears on one project, and the latest model collaboration integration with Navisworks promises much but doesn’t deliver. Want to collaborate models from other applications than Revit, sure they said, you can use IFC. What they don’t tell you upfront, is that it will only accept IFC models generated from 4 applications, and 2 of them are Revit, and MagiCAD for Revit.

Want to link in a Plant3D reference into Revit? It’s a horrible kludge of a process. Link an IFC model from Bentley Open Buildings into Revit? Not possible. Navisworks into Revit? Useless. Open a Revit model in Formit? Not a chance. Infraworks? Inventor? 3DS Max?

Autodesk is a $3+ Billion company that acts like a snake oil salesman, peddling tools that promise much but deliver little in the way of value of compatibility. It will soon discover how much is customers hate them.

Tools of Dubious Productivity

So when you’re against the clock working to complete a task, how much of your time should be spent massaging the ego of a recalcitrant software package? How much should the average user need to know about stability, memory leaks and the like? Looking back on it, a very significant portion of an operator’s time is spent corralling the code in a particular direction, working with the various foibles and “features”, well aware that autosave is not always there to save you, erm, automatically. This is totally off the top of my head, but I reckon that a good 20-50% of your time working on any given “productivity tool” is actually spent working within the limitations and boundaries set out by a Russian programmer called Petr. Or Vlad. Whilst my claim is no more accurate than a certain outgoing president’s claims of electoral fraud, unlike electoral fraud a loss in user productivity is really important. This is largely because large organisations like to make decisions based upon perceived percentages of productivity gain, versus sticking with existing legacy solutions, often sold to them by some vendor’s overzealous customer relations managers. Bold improvements in productivity are often trumpeted on marketing bumf but seldom is it mentioned that a certain proportion of that percentage improvement will be lost to “fucking about whilst the little beachball thing spins around”. Go to any busy design studio tomorrow and you can guarantee that at least one user has popped off to take a dump instead of sitting watching a percentage bar crawl across the screen.

To the nearest zillion, how many of these do you think Autodesk receive every quarter, filled with expletives?

I would be very interested to know what the actual percentage productivity gain there is from, say Revit 20xx, versus all the time lost to discovering new and wonderful bugs in this the latest iteration. Rather than always rushing to regurgitate the latest juicy morsels to the impatient hungry chicks, why not slow it down a bit? Mummy and daddy bird could eat together and stop off at the shops on the way home to pick something up for the kids. They could even get some groceries in and prepare something fresh using the cookery book by that fashionable celebrity chef when they get home. Exactly how this applies in the context of software development I’m not sure, but the point is that software development is so frenetic that there is barely a window of stability long enough when everything stops moving around for anyone to measure whether all these new, whizzy patches and add-ins are really helping as much as the vendors claim.

Now of course the image of a garden bird in chefs whites presenting Jamie Oliver style to mums wanting to improve their kitchen repertoire, is absurd. But then they were saying that about a Donald Trump presidency, and look what happened to that? Slow down the product cycle, I say, and aim to provide a competent core product that suits the majority of day to day users, instead of chasing some BIM panacea that so far has largely failed to materialise. Then, the true productivity gains can be gauged over a longer term, in a stable and reliable way, without all the bluster of the bestest and latest update muddying the waters. Also, I like the idea of little birdy chefs.