In May my 5th year in software engineering has passed. Before that I worked in Industrial Automation for 6 years as an electrical control systems engineer and I would like to compare my observations.
1. Designing for humans vs coding for machines
Electrical and mechanical engineers create drawings or schematics which are later used by shop floor workers, electricians and machine operators to create real life products. Drawings are therefore intended for humans, not machines, to understand. Rules governing technical drawings are complex but are nowhere near the level of complexity of computer languages. Technicians are usually good at interpreting the drawings, and are often able to spot errors before starting work. Also they often perceive engineers as disconnected and impractical (which is how software developers perceive architects). Because of that engineers can rarely afford to be completely socially inept and bad at communication.
Software engineers usually create code, which is compiled into working product by other software. The human interpretation is not necessary, although good teams perform code reviews to maintain cohesion, knowledge distribution and improve quality. Software engineers have a lot more control over the production process and there is often no intermediate layer of “human-based” processing between them and the finished product. Creating code for humans is not an intrinsic part of software development - however this is changing recently thanks to “Clean Code” and similar initiatives.
In a way, software developers are both
2. Standards and regulations
Standards are more significant in the electrical engineering, obviously. Many things are heavily regulated. For example, according to EN 60204 standard, wires for DC control circuits should be dark-blue, protective earth should be yellow-green. In theory different colors can be used, but in case of a failure or accident this may lead to financial claims or even criminal charges (e.g. if incorrect marking of a a PE wire kills someone). Standards are a double-edged sword - they must be respected, but when applied correctly they protect against claims.
Some engineering jobs are regulated by state. In Poland there is a funny situation now, where electrical engineers are subject to two different systems for constructions and machinery. Building construction is regulated with old construction code inherited from communist state - electrical engineers for constructions must therefore have an engineering degree and complete several years of internships (badly-paid slavery) in design teams and on-site constructions. At the same time machinery is subject to European Union rules, which are the same for all common market member states. Because of that pretty much anyone can design electrical systems for machinery. Hard to say how long it takes for any lawmakers to notice this schizophrenic division.
Standards create barriers for selling products to other countries. For example European Union uses EN 60204 standard for electrical equipment of machinery, but US uses NFPA 79. These standards vary in many small details (e.g. the abovementioned wire colors). European electrical engineer will have trouble to design a control circuit for a machinery intended for American market and vice-versa. The divergence of standards is even more visible in specialized domains like equipment for explosive atmospheres (ATEX). European ATEX standards are written using quite general language and high level requirements. American standards are extremely low-level and practical - they sometimes even contain dimensions of parts of equipment which must be used. I suppose both approaches somehow work (there are not that many explosions out there). Such limits in software engineering do not exist.
I remember visiting London for the first time and noticing that most of the electrical cables were placed inside metal pipes. Why not inside the wall? Did electricity work differently there?
Software engineering jobs are not regulated in Poland or anywhere else in the world. Software engineers also encounter standards in their job, but it’s usually very different. These are either low-level technical standards like RFCs, or business standards like Payment Card Industry (PCI). Both categories contain requirements and instructions, and both provide no or very little guidance to how software engineers should do their actual job. Software engineers try to make up for it by using design patterns and good practices like Clean Code, however these don’t have as strong status as standards. Software engineering is therefore much less constrained, but also there is more room for mistakes.
3. Community and education
There is a huge difference in the communities between standard engineers and software engineers. Standard engineers are sometimes members of “guilds” or industry organizations. These are not very active and have very weak educational impact. Personally I haven’t been a member of any of such organizations. Engineers do not have lots of opportunities to share knowledge outside of their workplace. Companies avoid sharing know-how with each other as the market is pretty constrained. During my work as a control systems engineer I observed several times that companies that were subcontractors turned to direct competitors (e.g. by entering industrial robotics area). Sadly this lack of know-how sharing extends also to general topics which can’t really be considered competitive advantages (like machinery safety, or electrical standards).
Most trainings for electrical engineers are paid and expensive. From my experience the quality is usually pathetic. I’ve completed an official 4-day machinery safety training from a well-known industry leader in that area and it was mostly worthless - the trainers seemed to have almost no experience with real-life machinery design. Free education comes from large equipment manufacturers who want to sell their new products. There are websites which are intended for knowledge transfer between engineers but they often turn into a cesspool of accusations and personal attacks.
Ironically I understood the role of a machinery safety engineer only after I became a software engineer. Few years later I read a Phoenix Project book, and there is an episode about the information security guy. One consultant explains to him that his role is to protect the organization against risk, not to complain that company is doing nothing to improve the security. Now I believe machinery safety engineer’s role is roughly the same - to protect the organization against claims, not to complain about lack of machinery safety.
When I became Java developer I immediately noticed that in software engineering everyone shares. You could approach an architect of another company and they would proudly tell you all the technical details of their solution. Developers would present their know-how on conferences, in youtube videos and blogs. I think there are two reasons for that. First, the market is global and huge, and there is enough work for (almost) everyone so companies don’t feel such a pressure to compete. Second, due to the nature of software, the IT projects are very often long-term partnerships, not one-shot deliveries - switching contractors is not easy in such scenarios.
Trainings in IT are also imperfect but they usually fail for different reasons - not because the presenters have nothing interesting to say, but because the training form is inefficient. I never attended any IT training where I had an impression that I should be the trainer. There are excellent online resources for most subjects, and many forums for knowledge exchange where people respect each other.
Community is in my opinion the biggest advantage of a software engineering job compared to other engineering jobs. As a developer you really feel a part of something bigger.
4. Tools
While it’s hard to directly compare engineering tools for different disciplines of engineering I feel that software engineers are privileged in this area. Very often software tool development requires the same skills as product development, and most competent programmers sooner or later become tool designers (sometimes shell scripts, sometimes full-blown solutions). On the contrary, electrical engineering skills do not help you automate drawing schematics or calculations.
In my days as an electrical engineer I used PC Schematic software, a Danish electrical CAD (somewhat popular in Poland). It was relatively decent and automated many things like references, numbering etc. However I still completed many tasks using Microsoft Excel. The spreadsheet templates were developed by the whole team and they were refined and improved when the understanding about the design process improved. Spreadsheets required synchronization with drawings on multiple occasions. For example selecting 24VDC Power Supply Unit (PSU) required summing up all the currents of individual sensors, PLC modules and solenoid valves in Excel and adding some room for expansion. It allowed adding the selected PSU to the schematic, which then required adding it to the list of AC devices to choose main circuit braker and supply cable (in another spreadsheet). There probably existed better CAD programs which automated this stuff (EPLAN maybe) but these were way too expensive for a small company. PC Schematic was a dedicated CAD for electrical drawings so it was still much better than the most basic solutions - there were people using bare AutoCAD for drawing electrical schematics, it automated even less. Software engineers have a lot better tools in my opinion. Compared to PC Schematic, IntelliJ Idea is much more complete - you can work on most tasks without leaving IDE, and it really goes extra mile to automate the boring, error-prone stuff away.
Another thing is version control. With the ubiquity of git it may be surprising that many industrial PLC projects are done without a decent version control, same with electrical and mechanical drawings. Version control is a paid add-on in some cases (Siemens), or an open source 3rd party tool is required. Using git is sometimes possible, sometimes it requires jumping through hoops, sometimes it’s possible at all. It’s not surprising that when I worked in electrical engineering, most versioning was done using zipfile snapshots of projects. Software engineers are really spoiled in this area.
Lastly, many of the software development tools are free to use, while engineering tools can be quite expensive. Free engineering tools are usually released by large companies (e.g. Festo releases tools for pneumatical installation design which supports their components etc.), in other cases by non-government organizations (e.g. German Institute for work health and safety releases Sistema software for machinery safety calculations. Such tools are a tremendous help when you can find and use them, but can’t be compared to software development tools like IDEs, version control systems, and CI servers.
Of course the dark side of software development tools is the variety and complexity of them. Software engineers really need to learn a lot more to stay up-to-date with the latest developments.
5. Sales
Many engineers and software engineers never take part in sales process, I had an opportunity to experience it in both settings. My first observation is that in electrical engineering role my work was sold as a percentage of machine costs. I’ve never estimated any tasks for large project sales purposes, I’ve made estimates for small one-shot changes only. Control systems engineering was a small and relatively inexpensive part of the whole machinery cost, so there was no real need to precisely estimate it. When I started working as a developer and later team leader, I had to learn to estimate tasks. Obviously in software development the biggest cost is the work of developers, analysts, QA and devops so it is the main component of the project cost.
Second observation is not very original - software is really hard for clients/end users to define. With machinery projects the company and clients had some failures with preparing offers. In one case both sides forgot about a 30m conveyor. In other case robot cables were 10 times more expensive than planned (elastic versions). Many times the machines had problems with achieving desired capacity. These are all serious issues, but in none of the cases client ordered something completely unnecessary or unsuitable for their needs - and this is what happens in software projects all the time.
Regarding salesmen - I would say that machinery salesmen were ultimately more truthful. Software salesmen proudly sell dreams. Yay!
6. Projects
Electrical engineering is tied to real-world processes like ordering materials, assembly and delivery. Some things cannot be shortened. Mistakes in project (or in order) cannot be easilly hotfixed. Testing machinery requires assembling physical components. Because of that waterfall is the only feasible methodology for machinery projects. On the other hand, many software projects function with agile methodologies that assume that some of the work will not be accepted by an end user and will be thrown away. This is possible because the main component of the final project cost is the labour. If software companies work with waterfall methodology, the process of collecting requirements from the end users is much more thorough than for machinery engineering. Collecting requirements for software is more difficult because the processes are more complex, but maybe also because the abstractions developed by software industry to describe deployments and integrations are not entirely sufficient (i.e. there is no common way to describe how the application will be deployed or integrated with other systems).
There are also differences in QA - in electrical engineering the most common QA tool are the peer reviews. I have not seen any tools for simulation or formal verification used for low-level testing for electrical or pneumatical circuits in the way that developers use unit tests. However in wider automation domain there are simulation tools for whole machines and installations (I had opportunity to work a bit with Finnish Visual Components software). These tools can be tremendously useful when applied correctly. These tools can be thought of as equivalent of IT integration or end-to-end tests. Note: simulations produced by such programs can often be used as an efficient sales tool.
7. Ambition
With both normal engineering and software engineering it’s possible to work in ambitious, innovative organizations, or in weak, backward ones. After 30 years from the collapse of the Iron Curtain, Poland economy is still very much dependent on foreign investments and companies. Number of engineering companies is not that big - in my city there were 2 or 3 decent ones. If a foreign corporation builds a manufacturing plant from scratch in Poland, it designs the machinery at home and brings finished equipment with them. Because of that it’s hard for local companies to score really big projects, however that doesn’t mean a company cannot innovate. Sometimes innovation is forced by worse economic situation. For example we noticed that robots in installations designed by Western European countries were relatively underused - they were programmed to perform one task (like placing carton boxes on a pallet). All supporting actions like dispensing pallets were done by specialized machinery. In Poland the robot had to pick and place carton boxes, pallets, separators etc. It reduced cost and size of installation but decreased reliability and required a lot more engineering.
Software development in Poland is completely different - compared to machinery manufacturing it is a huge industry. There are dozens of companies, most of them however are software houses without their own products. The technologies and architecture are dictated by foreign clients and these are often old, maintenance projects, although new greenfield projects happen too. Innovation in such organizations is usually quite hard, as all important decisions are made elsewhere. It’s much easier to innovate in companies with their own products and I feel like this is ultimately better choice for software engineers serious about their work.
I would say that software end user satisfaction is a bit lower than with machinery (strictly personal opinion). There may be multiple reasons for this - first of all end users in machinery industry have very clear goals (e.g. 1000 boxes/h, one day of downtime every two weeks). Software end users goals are usually not that clear and it’s much harder to determine if the software is the best choice for the job. Secondly companies and users often prioritise new functionalities over fixing bugs. Thirdly the UX design approach is still not as widely adopted as it should be - applications are slow, clumsy and hard to use.
Bonus: is software engineering real engineering?
Sometimes people refer to software engineering as “not real engineering”. It depends on the definition of course. My father once gave me such a definition: an engineer is a guy who knows if the system is going to work in real life conditions. When there’s a measurement “x”, engineer can give their judgement: “that value is okay, we have plenty of room to expand” or “it’s too high, we should decrease the capacity” or something else. Everyone who ever tried to do such thing knows that such reasoning is notoriously difficult and requires a lot of experience and knowledge. Next step is to modify the system to change the desired values. It is even more difficult, as real-life systems are always complex, and their parameters are strongly coupled.
According to the definition above software engineering is undeniably “real engineering”. Developers need to understand their systems metrics, and choose solutions that improve the operation of the system.