Viewpoint: Don’t sacrifice engineering principles in a pandemic
Author : Colin Funnell | Development Engineer | Hitex
01 September 2021
Hitex_Viewpoint - Don’t sacrifice engineering principles in a pandemic
Times in business are tough, no two ways about it. But as Colin Funnell, Development Engineer at embedded systems expert, Hitex reminds us here, many engineers are lucky enough to be able to do the majority of their work on a computer from home – and still have new work coming in. We’re also fortunate to live in an era of high-speed connectivity – without which, the majority of home-working would simply not be possible.
This viewpoint was originally featured in the September 2021 issue of EPDT magazine [read the digital issue]. And sign up to receive your own copy each month.
Over the years, I’ve seen the classic engineering design flow being pushed further and further away. Times change, new management ideas come along and grow in popularity, toolchains evolve and are used in new ways. During the coronavirus pandemic, the world has jumped at remote working tools to allow the continuation of business. I’m certainly not opposed to change, especially if it helps makes things better, but I’m also not convinced some businesses are handling engineering very well in these modern and challenging times.
The classic approach
When I say the classic engineering approach, to me, it remains the approach that should be used. It is outlined in incredibly simplified terms below, but it is amazing how many businesses or departments really don’t want to follow even this. Maybe it’s due to speed, cost or business constraints, but I see it happening more and more.
• Set requirements: decide what you really want and need, up-front.
• Design to requirements: becomes a turnkey approach, if requirements are properly set.
• Build & test to requirements: does it do what it is meant to?
Nobody likes unnecessary documentation, but it’s vital for both parties to agree on what they want, and what will be delivered. If anything, it helps clarify things between the customer and the provider – which can only be a good thing.
Everyone is running late
“It will work, because it has to” is a project planning maxim I’ve heard many times. It’s normally a tongue-in-cheek explanation for project plan shortcuts, where time has been lost, but end dates remain fixed. Project plans are never accurate, but this year, the COVID pandemic has provided a good reason why manufacturing, the component supply chain and basically every business has been affected. The whole world knows this and understands why.
This makes the sudden surge to meet original deadlines by bypassing normal design flows and testing a dangerous idea. Many companies which were cued up early in the year for design work suddenly clammed up. This did give rise to customers having the time to review secondary projects, which has proved good for business. But the original customers also came back, armed with a plan. And those plans were basically to do everything quicker and test less, in order to meet the original timescales they had committed to their customers. Hitex rose to meet those challenges, but the story doesn’t end there.
As soon as designs were finished, customer eyes turned to volume production. Planning ahead isn’t a crime. Trying to build hundreds of units that were not only fractionally tested, but also had fresh PCB changes, means adding a huge amount of risk. The smallest of issues now gets multiplied up. Something that could be easily modified on a prototype now becomes a major piece of work, covering many units. Manufacturing prototype batches helps ‘pipeclean’ the production processes, to weed out initial niggles and silly mistakes. Needless to say, projects that tried to operate like this had setbacks. Setback being a rather polite word.
Using “It will work, because it has to” is only practical with the benefit of hindsight, on projects that did turn out OK to justify its use. If you decide to take risks, prepare for consequences.
The bigger picture
Another area where there seems to be a trend is the ‘Agile-like’ approach to everything. I’m not an expert in Agile methodology, but I can see its benefits in modern software development, to focus development work. I say Agile-like because I hear stories from practitioners of its misuse or half-hearted implementation. People seem to think that repeatedly pouncing from one very narrow problem to the next is how to design. I can see its value as a way to attack bugs or develop features, but not to develop an architecture or hardware.
Hitex_Viewpoint - Don’t sacrifice engineering principles in a pandemic
Hardware and architectures in general require a holistic approach – the whole must be considered in one go. Normally you can’t easily alter one part without influencing something else. If you have an architecture where you can do that freely, it sounds like everything is nicely isolated from each other, but possibly over-engineered or generic.
Trying to attack one aspect at a time means there will be continual change until everything has been considered. This is fine if you are discovering what you need in the early phases of a project. But it’s just plain backwards if this is being done while everyone is trying to design their contributed parts for the system. Every change has a ripple effect throughout the project. What was previously being designed ends up being stretched, tweaked or just ripped-up. And for hardware design, it’s normally the latter.
There is a knock-on effect if work is constantly having to be re-done, and that’s people’s care and attention begins to wane. There’s no reason to put the attention to detail into a design if it is just going to be altered again. That will be left to a review – if it ever gets to a stable point. With a firm set of requirements agreed up-front instead, the approach should be “do it once, do it right”. Nuances get considered as it is being designed, and are checked along the way. By the time it gets to a review phase, the reviewer can now concentrate on real potential issues, instead of uncovering problems of a design that has been changed and changed again.
“Problem pouncing” may feel empowering to some; it can certainly look good in management circles, with rapid progression from one issue to the next. But this is trying to design by reaction – not with a clear overall view of what they want to achieve and filling in the minor detail. When starting a design, this approach reeks of not knowing or understanding what you really want.
A typical project group meeting might go something like this…
One person will ask “When will it be ready?”, while another asks for the latest list of newly discovered problems. Clearly, one person has the task of removing blocking factors, while another is there to make sure the build occurs on time. These two parties have their targets, but the overall approach means they are in direct conflict with one another. A fixed end date cannot be projected when the design approach is to “think about the next problem when we get to it”. A date can only be given if everything that needed to be known has been sought. Other problems weren’t anticipated because everyone was concentrating on the immediate task in front of them. Tasks were being assigned and people were completing them. Surely, a manager’s dream! It was never going to end well, but all the individuals were happily doing their part and management have a metric they can report. The project lacked the initial design and any coherence. These type of approaches have their place, but only really once the platform has reached some level of stability.
Remote-working with chat channels
Many engineers are working from home now. Initially, project managers anticipated huge problems keeping everyone involved and didn’t want teams being broken up due to lack of communication. Remote chat technology provided an ideal solution. It has proved really useful for quick over-the-shoulder questions to a colleague or discussions that may normally have come about informally in the company kitchen.
But it’s not a solution that easily scales up and certainly isn’t a magic bullet to trying to manage many people remotely. In short, lumping more and more engineers into a chat channel is not, in itself, an effective way to drive discussions forward. Management may have ticked a box to keep a team together using these tools, but it still requires management of the team.
A project needs requirements bottomed out by taking decisions. This does not happen in a collective chat, especially full of engineers with their own take on the matter. It can even have the opposite effect of wandering off-topic and diluting the focus by adding more people. Trying to appease all these opinions is simply impossible. Design by consensus never has and never will work. The collective noun for many engineers in a chat room might as well be an ‘indecision’.
Discussions that feed into a set of requirements are always welcome. However, formal documentation must be still be pursued. If there isn’t a clear action to create it, it won’t happen. It’s not going to naturally emerge from a chat room.
The video meeting from home
Hitex_Viewpoint - Don’t sacrifice engineering principles in a pandemic
Video meetings can be beneficial. In 2020/21, I’ve been glad to see some faces on-screen, even though I’m not overly keen to being seen on-screen myself!
Ineffective meetings have been the scourge of business since… well, the dawn of business. I’m all for a little social interaction during these meetings, but since so many people now have meetings for the sake of them, many risk becoming a waste of time with very little focus. Some form of agenda and minutes are required. It needn’t be too formal, but at least have the essence of them to focus people’s attention. Even attempting to run a proper meeting produces more structure than none at all. Better still, let’s not have them at all if they’re not actually needed!
Regular scheduled meetings can be a double-edged sword. Knowing that progress is expected at the next meeting can spur people on. But if you’re really busy, then having to go into a meeting for the sake of it can be wasteful.
During the last year, the number of remote video meetings has unsurprisingly increased. The downside has been that of these meetings, a large proportion have been ineffective. It was very clear that someone had decided they ought to have them, but less thought went into the objective for them. Some of the worst I was involved with had the host manager asking about blocking factors, but then having to jump to the next scheduled meeting before the real nature of the problems could be discussed. The next time it was going to be discussed… was the next video meeting, or a chat-channel.
At least if you’re going to have meetings, turn them into something useful and follow through anything raised. Another meeting is easily arranged if required, to avoid keeping other people tied up on the call. Conversely, regular meetings can be cancelled if there is no need for them. We have the tools to be flexible about this, so let’s do it. No need to book a meeting days in advance if everyone in a chat group is happy to meet there and then.
Shared live documents
Of all the modern technologies, this is the one that causes the most grief – not by its nature, but through its misuse. In a time when business needs to “get things done” and staff are remote, this looks like a really handy tool.
I have seen one company use live documents for absolutely everything – not only specifications, but architecture diagrams and even databases. It was a bad start when to get a grip on things required multiple system logins, and a crib sheet to point to all the relevant documentation. Everything was dispersed and continually evolving. What was needed was the information published as a fixed point, along with all other project documents, in a single place.
So many documents were left as live, since people understood there will be some changes. But leaving the door open means that people will make changes. Or worse, not bother with early versions, knowing that changes can be made later on, when convenient for themselves. Passing on requirements in this way should just be banned! It’s not clever, only pretending to be flexible, and it’s certainly not useful. The goalposts will always be moving, and you can never claim to have met them properly. It’s a no-win situation for everyone involved.
By all means, live tools are a fantastic way to help create documents – but they must eventually reach a stable, finished point. Any form of quality management will insist on this, so they can be referenced.
Summary
With proper documents in place, there is much less reliance on homeworking collaboration tools and the constant chatter that seems to go along with them. Online tools can be a great help communicating, enabling the discussion of ideas with everyone so dispersed. But with good engineering practices in place, they aren’t essential. It would be wrong to think that working from home requires using these tools as often as possible. Real-time communications can become real-time interruptions. The traditional set of specification documents, being clear and concise, are the primary inputs for any engineer to work with. Work can continue at a great rate on these alone. For the missing detail, communication tools can then be used to great effect.
If the client is unable to create a requirements specification, then they don’t know what they want. If they don’t know what they want, then they’ll never be satisfied with your design!
More information...
Contact Details and Archive...
