#begin
So what is engineering? We all know that software developers like to borrow analogies and metaphors from other fields like: software architecture being borrowed from civil engineering. It’s often difficult to explain what the engineering part of SE means exactly. So let’s see what David’s opinions are.
He starts by saying that production is not our problem. And he’s right! Actually producing and deploying things is so easy, we can build, test, deploy and run our software with a press of a button. Quite literally!
Our problem lies more in the design space. Finding the best technical design for your software is far more difficult than actually deploying it. We need different kinds of techniques than civil engineers do. We need to be able to iterate rapidly and test often. That’s a privilege civil engineers wont have. Maybe when they use simulation software they can to a certain degree, but not on the same level as software engineers can. David then mentions SpaceX blowing up rockets on test stands at starbase trying to perfect its StarShip rocket. This is indeed an iterative software engineering process applied to physically engineering something. People who are not familiar with the process might think all these tests are actual failure but that’s not the case. Last week Elon did the first actual test flight with the fully decked out StarShip rocket. It ended with a nice explosion and that’s what we all see in the media. These haters making headlines saying like: “Elon’s new rocket explodes mere minutes after launch”. They are factually correct but fail to mention that the test actually succeeded. I guess this has to do with the hate Elon attracted by his Twitter purchase…
But to get back to the book: SpaceX has produced a high number of prototypes to evaluate whether their designs are any good. If you can think of any other company that does development of rockets this way I would like to know. So they applied a software development process to actual engineering which I think is pretty interesting.
David mentions the following: “Software development, unlike physical production processes, is wholly an exercise in discovery, learning and design. Our problem is one of exploration, and so we, even more than the spaceship designers, should be applying the techniques of exploration rather than the techniques of production engineering. Ours is solely a discipline of design engineering.”
This relates back nicely to David’s definition of SE from the previous chapter. But he applies it to a broader spectrum of engineering which now goes as follows:
Engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems.
So engineering is about applied science! It has lots of practical elements and we use empirical data to advance our knowledge and solutions towards solving a problem.
David then rightfully mentions the fact that engineering has nothing to do with code. For software engineering it plays a part but it’s not the main aspect. It’s about creative and technical problem solving, management of a software project and risk analysis. It’s about the entire process that spawns software into existence. So when David talks about SE he really means everything that’s involved with creating software from beginning to end.
But why does engineering matter, really? Well David says that a lot of production historically or new is still based on a craft-based system. He says craft-based systems are work very well at creating one-off items where each individual item is unique and special. But when you move to production you need to create fast and often with high precision and repeatability not to make things differ too much.
I never really thought about it this way. I’m a big fan of the software craftsmanship movement and I suppose that’s because I mainly wrote very custom systems for customers. But when you for example write “generic” cloud services you need them to be precise and repeatable. I do recognize more of an engineering approach to some of the projects I write for my own. That’s because I often write plugins, libraries or frameworks to support a wider range of development. So in that sense I do feel there is a mixture of engineering and craftsmanship.
Another interesting point is that craftsmanship is really, really important in game-development. You can engineer the heck out of a game and all its systems and architecture, but it needs crafters to make it truly interesting and fun. I guess that, in the game-industry, the balance between craftsmanship and engineering is very fine.
According to David there are two differences between craft and engineering: Engineering highlights precision and scalability. Precision is rather obvious. You manipulate things at much higher resolution of details through the application of engineering techniques than by hand. Scalability on the other hand may be less obvious. David gives an example of manual testing (craft) vs. automated testing (engineering). Manual testing is limited to the amount of work a human being can do, whereas automated testing can be done very very quickly by a machine.
I think this example is a bit weird because if we take a look at the craftsmanship movement, testing and TDD take center stage. So associating manual testing with craft seems a bit weird to me. But then on the other hand, at Dephion, manual testing was the way to go. You could add unit testes all you want just for the take of managing your own sanity but the QA team had the final say in everything anyway. So functionally I could prove things were correct by unit testing but QA will point out the more esoteric issues like UX, fun factor and if things make sense. This is indeed more about craft and opinion of our awesome QA team and is very difficult to encode in a machine to automate in an engineering approach.
Another reason why engineering scales is the fact that through engineering you manage complexity. Engineering thinking tends to compartmentalize problems. So it divides large problems into smaller problems which are more easily solved. This reminds me of another great book called the structure and interpretation of computer programs where they essentially say the same thing. Build small things and compose them together to forge large awesome systems. This is at the hearth of good system design no matter your programming paradigm. People often associate composition with functional programming but it can and must be applied in an OO context as well.
In engineering, design must be modular, composable, repeatable and standardized. Without it, engineering makes no sense anyway. This is the true reason why engineering scales, and craft does not. As mentioned before, craft is about creating unique and one-off items, which simply does not scale.
David then mentions the craftsmanship movement saying it was a very good move to get away from waterfall-like processes. Software craftsmanship was a way better fit for the type of problem software engineering really is. But craftsmanship is not scalable and we now live in a world based on scalability related problems. So combining ideas from craftsmanship and engineering is the next level. We need to be design-engineers, not production engineers. According to David, craftsmanship tends to focus on production, not design.
I think its difficult to pin this down. For me, craftsmanship is about being proud of the software you create, and creating the best possible software for your customers. There will always be an aspect of engineering in this process even when you align more towards craftsmanship. Thus I think a fine balance of engineering and craftsmanship is the way to go. As with anything in software (or life) being absolute or dogmatic will not get you to the end result in the best possible way. There’s always a balance.
David ends this chapter with a preface on how to transition from craft to engineering, without dismissing the values of craft. I think we have established the fact that craft in and of itself is not a bad thing but it just doesn’t scale enough. As software engineers we need the high quality craft provides and thus we need engineering to amplify quality. Craft is often associated with creativity and software engineering happens to be a deeply (technically) creative process, but so is engineering itself. The remainder of this book will dive more deeply into this subject. It will present a list of fundamental principles.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments