Consultant selection

Inilock began manufacturing locks in the 1880s and has always taken a conservative approach to changing the way locks work. But the world has moved on and pins and tumblers have been replaced by his RFID card readers and electromagnets.

Inilock didn’t have the in-house expertise to build industrial locking systems for commercial customers, so it did what any company would do and hired highly paid consultants. This project started in his 2018 year. These consultants built lock firmware platforms, servers, and homegrown TCP protocols to handle configuration and setup, delivered it late and over budget, cashed their checks, and were gone by 2022 .

The system wasn’t bad either.it was very bad. The server used to configure locks hangs on regular servers. That’s bad enough, but what’s worse is that it locks you up. Also Stop responding. After all, “Did you try turning it on/off again?” is not the question a customer locks out of a building wants to hear. The product was so poor and consumed so many resources that Inilock was facing an existential threat.

They hadn’t gained any new expertise in software development, so they hired another consulting firm. christian enters this story. His team is brought in to try to resolve this disaster before Inilok locks their doors for good.

The first thing Christian did was track down the source control server and start reading the code. The server is written in C# and the project was started in 2018, but all the choices made were frozen around 2008 and the database access was updated with .NET. framework, ADO .NET was used.

It was a hassle, but more important was the release process. There was no CI/CD. The developer pulled the code, ran a “Build…” on his local machine, and uploaded the binary to his FTP server. Another tool can be run on the target network to retrieve the binary and distribute it to all locks on that network.

This gave Christian a sense of the overall care that went into the project, but when he researched the network protocols and how they were handled, he realized why using this software was such a terrible experience. started.

The configuration application wrote a record to an MS-SQL database. Another service periodically queried that database. When data changes, the new configuration is broadcast to all locks via a proprietary TCP protocol. An endless loop reads data from the database, converts it to XML, sends the XML over a TCP socket to each client, and queries the database again. Well, almost infinite.

What this service doesn’t do is any kind of error handling. Oh, no breaks were inserted into the stream. It also did not provide a way for the client to know the expected length of the data stream.

Every client had a buffer, scanned it every 50ms, and assumed everything in the buffer was a single message from the server. This was fine in an experimental environment where there was little traffic or delay on the network, but in a real network, either the client would check the buffer frequently before the entire message arrived, or there would be two Messages may be left behind. Since there was no error handling on the client side, invalid data was left as is.

Also, the server didn’t have error handling, timeouts, asynchronous messaging, etc., so if those connections went down enough, the server would hang.

It was a lot of work to remove the messaging layer and replace it with a third-party library that was fit for purpose, but it was enough to solve the reliability issue and improve the system’s performance by 1000%. The architecture is still a goddamn disaster, the UI is still a nightmare, there are still all sorts of bad choices and crashes, and the only parts of the codebase that have automated testing are: That’s the only part that Christian’s team touched. But it went from a large train wreck of toxic waste to a moderate train wreck of toxic waste.

Whether it’s enough to save Inilok remains to be seen, but when Christian cashes the check to become a consultant, he at least knows he’s made a difference.