Links to talks that where referenced in this video: Is Software Engineering Still an Oxymoron? • Alan Kay • GOTO 2021 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-D43PlUr1x_E.html Progress Toward an Engineering Discipline of Software • Mary Shaw • GOTO 2015 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-lLnsi522LS8.html Modular Monoliths • Simon Brown • GOTO 2018 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5OjqD-ow8GE.html
Designing software isn’t at all like designing a building or a bridge. Software is about abstract business processes and cultural processes and the flow of data through those abstract processes. Software is fluid and changes over time whereas buildings and bridges require rigidity. For this reason, engineering and software engineering will always require very different processes and approaches.
Agree. Also - when a client wants a bridge over a river, or a building that will serve a certain goal - it's usually a well defined requirement/problem, which is different for software where we usually figure out what the problem really is on the go (together with the client) and it changes over time because the business environment and world changes.
I think that this is not a very accurate view of engineering or bridge building. Early planes were worse than modern planes, they evolved and changed purpose, design, construction over time through a process of engineering. Bridges change patterns of use, and are modified over time if patterns of use change. Sure, software amplifies this need for malleability, and shortens the timescales, but there is no such fundamental difference. Engineering is not about defining some fixed solution to a problem, all bridges and all planes aren't alike. Engineering is about ruling out the dumb ideas, and we aren't very good at that in software. So I think we need more engineering thinking, and this is perfectly applicable to software, and when you work in a more structured way, you build better software faster.
I also don’t think “production is free” is quite correct either. Maybe it applies in the case that development actually succeeds. I know several multi-hundred million dollar software projects that failed and were abandoned.
What Dave was saying is that we don’t have to build our systems from scratch again to put them into a production environment. We build them in a development environment, and the work that was done can be transferred into a production environment at no extra cost. So in that sense - yes, production is free.
Testing micro services independently is not really possible without well defined contracts. To say that micro services are independent is an exaggeration
No agility in software development, it was and still is a long tedious process, and no viable shorcuts available. Yes process franework like scrum is important but does not automatically guarantee a good software. You still need to put in the work, hard work. When these people talk they surely inspire, until reality hits you. It is still up to you and your team and your actions that determines what will be the outcome.
Building better software faster is a very poor focus. Actually, it's not a focus at all. Building bad software fast - is a good focus. If you can build 100 products instead of one, and every one is only 10 times worse than that theoretical one, you multiply your chances to success tenfold. Building good software slow - is also a great focus. We definitely need mission critical software and we have time to build it. I used to work in NPP automation, we had 30-years long maintenance contracts there. If you're aiming for decades of maintenance, you can certainly afford years of development. But targeting both quality and quantity at the same time is not a focus, it's a bad case of astigmatism.
