One of the most interesting and distinctive aspects in the Maker approach is learning by experience just enough to be productive.
This is one of the reasons why we did not hold back from this project’s challenge, although we don’t have full technical knowledge in the automotive mechanics field.
It’s interesting as well to realise that methods and concepts used in certain application contexts can prove equally useful to address problems seemimgly very different from those they have been defined for.
In the current phase of iaiaGi, we are defininig the key characteristics of the suitable electrical motor to be employed in a class B vehicle conversion.
Thinking about engine replacement, it comes natural to reflect about which should be the best approach to plan the old engine replacement process with a new one.
In these reflections, an important concept in Software Engineering and Agile Development came back to my mind: the refactoring.
And with a bit of surprise I realised that all valid approaches in software refactoring may be applicable to our car conversion project.
Refactoring is a restructuring operation for a software program where a portion if its code is redesigned and replaced with the constraint to keep the general program behaviour unaltered. Reasons for such replacements are usually aimed to gain an improvement, quite often related to performances, code maintainability and extensibility.
Software refactoring takes in general these steps:
- identify the section of code to modify
- outline a “boundary” identifying the least number of well defined interactions between that section and the rest of the source code
- define and document all interfaces on that boundary
- proceed with the complete redefinition of the section to replace, so that the defined interfaces do not get modified in structure or behaviour
- at the end, regression tests are performed.
It is interesting to notice that if we think about an automobile in place of the software and we consider a section of it (e.g. the engine), the steps listed above stay absolutely valid:
- The section to modify is the engine
- The boundary includes all those connection with other devices that can be disconnected and later reconnected without altering the interaction modes.
- These connections are the interfaces
- At this point, with the aim to remove the engine completely, it is necessary to analyze and design how all these interfaces will be operated in unaltered manner, despite the fact that now a three-phase asynchronous electrical motor is in place of the previous internal combustion one.
In real complex software restructuring cases, a complete re-integration of all functions and interfaces is hardly achieved.
This follows, for example, from a starting source code being too poorly structured to allow an effective analysis or when, for prioritization, some pre-existent functions can be temporarily disabled for future reintegration.
The same holds for a vehicle conversion, I would say.
When disconnecting the former engine, few things may happen:
- Some interactions can be reused as is (e.g. the clutch disk)
- Some will be made useless (e.g. the carburator, the fuel tank, the exhaust silencer…)
- Some other may be used only partially and some more will need to be deactivated (e.g., all the control lines from the main controller unit).
We will be able to analyze and plan the motor conversion steps with the same mental process used to operate a refactoring for a software program.
Exactly as with the software, the deeper the knowledge is about the original system, the more effective and fast executed the refactoring will be.
This suggests the importance of spending time in knowing in detail how a traditional IC engine works and how its sub-parts interact.