To Speed Up, Slow Down and Leverage – Especially in Software Development
Darian Muresan
Teaching Professor, Stevens Institute of Technology, and Chief Technology Officer at Computer Vision Company
In leading software development teams for almost two decades, I have learned that good software development is notoriously difficult. In 2005, an IEEE Spectrum article entitled “Why Software Fails” discusses this problem by highlighting several different reasons why software projects fail and the costs of these failures. Here is one particular quote that brings the issue of software development failures into focus:
“When you add up all these extra costs, the yearly tab for failed and troubled software conservatively runs somewhere from $60 billion to $70 billion in the United States alone. For that money, you could launch the space shuttle 100 times, build and deploy the entire 24-satellite Global Positioning System, and develop the Boeing 777 from scratch—and still have a few billion left over.”
The article goes on to highlight several valid reasons for software failure, including: unrealistic goals, badly defined requirements, sloppy development practices, poor project management, politics and others.
Among many of the reasons for software failures, I would like to focus on the “sloppy development practices” and to suggest one over-arching approach to removing the “sloppy” adjective from software development practices -- an approach that has worked well for us at DMMD and Iconasys.
First, it is important to understand the reasons why software development has an innate tendency to be sloppy. Chief, among them, is because software development can be done with minimal amount of resources and training. All you need is a computer. At the entry level, all programming languages are intuitive and therefore, almost anyone with a computer can program. This translates into software development being a “high velocity engineering discipline.” How many times have you heard a developer say: “ah, that’s easy! I’ll have it implemented in no time!?”
Compare this with other engineering disciplines, such as the development of circuit boards, building bridges or almost any other engineering discipline. Construction in Civil Engineering requires a lot of system design and analysis, diagrams and paper plans, before even one brick is laid, or a cable is strung. Bridges, unlike a lot of software, are carefully pre-planned on paper and then implemented following a clear plan. I would venture to say that almost all other engineering practices have a “lower development velocity” than software development. In other words, building the simplest project, in most other engineering practices, takes longer than building a simple software project.
Second, if our estimation of the problem for “sloppiness,” in software development, is its “high velocity,” then an intuitive solution might be to design a way to slow things down, so that software development has a development velocity more in line with other engineering practices. This is a good intuition. The art, however, is in how to slow down this development velocity in a meaningful way. To answer the “how” I will turn to Archimedes and one of his quotes:
“Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.”
Combining Archimedes’ wisdom with software development, my recommendation to removing sloppiness from software development is this:
“To speed up, slow down and leverage.”
To me, leverage in software development means designing small modules, with very concise and clear responsibilities and interfaces, in such a way that these modules can be re-used multiple times. Writing re-usable modules will slow down the short-term development process, making it more in line with other engineering disciplines. Further, it will have a huge speed-up impact, long term. Not only does it remove the sloppiness from software development, but it will speed up the long-term efficiency of future development.
In conclusion, good software development can be notoriously challenging, and billions of dollars are wasted each year on failed software projects. Software projects fail for many reasons, one of which is sloppy development practices. A software development mentality of “slowing down to leverage” can have a huge impact on removing sloppiness and “speeding up” the long-term goals of any project. This approach has worked well for us at DMMD and Iconasys.
Teaching Professor, Stevens Institute of Technology, and Chief Technology Officer at Computer Vision Company
5 年You and I talked, in the good old days, about building software like Ikea furniture or Lego pieces. These are difficult problems to solve because they take more time, thought and skill – especially when there might be an easy non-modular, one-time-use solution at hand. Generalization, thinking of multiple use cases, is hard and it takes practice, some would say it is an art-form. However, this additional time and thought process is what forces good software development practices, what slows down the process in the short term but can provide increased development speed down the road. Once modules with concise and clear responsibilities are developed and tested, they provide solid building blocks to more complex configurations down the road.
LiDAR Calibration and Test Manager at Luminar Technologies
5 年I agree with the modular or unit approach, and yet, in my experience, there remain difficult problems in certain application domains. In particular, any systems defined as finite state machines (or in need of such definition) are always problematic because of the challenges involved in ensuring there are no undefined transitions to and from states that could actually manifest as catastrophic bugs. Of course, this is a problem on the other end of things—at run-time. Still, well-defines modules definitely prevent many problems up front. What remains is for tighter coupling between developers and SMEs who prototype, for example, embedded control systems, in environments like MATLAB/Simulink.