The way to battle bugs effectively, is to reduce the system complexity, and to train your programmers. If necessary, throw it out and start over. Be relentless.
A.E.Veltstra
April 18, 2013
A piece of software encompasses many layers of complexity. This is captured in the ISO-OSI model. Depending on the kind of software we meet hardware, chip instruction set, operating system, security, maintenance and networking (maybe loadbalancing), database and drivers, runtime environments, application layer, and finally the application.
With web applications and other 3-tier systems we usually encounter middleware. Sometimes storage is located in the "cloud", a fancy word to indicate a distributed filesystem accessible via the internet. Sometimes the application layer requires services by third parties, webservices like Google Website Optimizer or MailChimp, for instance.
Each layer is transparent and a black box to the other layers. Transition between the layers can be achieved statically using compilers, and dynamically using interpretors, or via A.P.I.s (application programming interfaces). Each layer adds to the overall complexity. Thus, when bugs appear, they can have their cause in each and every one of those layers.
For that reason, I am reluctant to add to that complexity.
I question the need for a javascript framework like jQuery: I do understand javascript. I question the need for a CSS preprocessor like SASS: I do understand CSS.
I question the need for a "visual" programming environment like MS Visual Basic and its visual brethren, or Microsoft's Webforms to create websites, or the Zend framework for PHP, or a CMS product that uses its own programming language, or Google's java intermediary: they hide too much from what actually is going on, they have their own compiler that does things its own way and requires additional study to understand and manipulate, and if something goes wrong it can be quite the handful to figure out how and why.
Did you ever come across an exception in jQuery, where the interpretor suddenly claimed that "the object doesn't have that property", and didn't know how to solve it?
Exactly.
The problem isn't jQuery itself. Instead, it's that each layer adds to the overall complexity, increasing the time required to hunt down the bug.
We can reduce the chance for known bugs by creating unit tests. Unfortunately, we can test only that which we can predict will happen, and only that which we control. We usually do not control the database driver, so testing it is limited to comparing actual with expected output, and even then we have to wonder whether a problem occurs due to the driver, the database, or our request.
Unit tests do not help us with edge cases and situations we didn't predict. In software, there is no such thing as "getting it right". There's only getting something to pass the tests. Tests can be flawed and necessarily are incomplete. As a result, bugs will occur. Ignoring that fact, caused by a misplaced belief in the infallibility of unit tests, has been shown a fallacy.
The way to battle bugs effectively, is to reduce the system complexity, and to train your programmers. If necessary, throw it out and start over.
Be relentless.
I understand that can be difficult. It hurts our pride to throw out something that cost us a lot of time and effort, something that made us proud. But it its complexity makes it too hard to debug, dump it, learn from it, and make yourself even more proud.
With web applications and other 3-tier systems we usually encounter middleware. Sometimes storage is located in the "cloud", a fancy word to indicate a distributed filesystem accessible via the internet. Sometimes the application layer requires services by third parties, webservices like Google Website Optimizer or MailChimp, for instance.
Each layer is transparent and a black box to the other layers. Transition between the layers can be achieved statically using compilers, and dynamically using interpretors, or via A.P.I.s (application programming interfaces). Each layer adds to the overall complexity. Thus, when bugs appear, they can have their cause in each and every one of those layers.
For that reason, I am reluctant to add to that complexity.
I question the need for a javascript framework like jQuery: I do understand javascript. I question the need for a CSS preprocessor like SASS: I do understand CSS.
I question the need for a "visual" programming environment like MS Visual Basic and its visual brethren, or Microsoft's Webforms to create websites, or the Zend framework for PHP, or a CMS product that uses its own programming language, or Google's java intermediary: they hide too much from what actually is going on, they have their own compiler that does things its own way and requires additional study to understand and manipulate, and if something goes wrong it can be quite the handful to figure out how and why.
Did you ever come across an exception in jQuery, where the interpretor suddenly claimed that "the object doesn't have that property", and didn't know how to solve it?
Exactly.
The problem isn't jQuery itself. Instead, it's that each layer adds to the overall complexity, increasing the time required to hunt down the bug.
We can reduce the chance for known bugs by creating unit tests. Unfortunately, we can test only that which we can predict will happen, and only that which we control. We usually do not control the database driver, so testing it is limited to comparing actual with expected output, and even then we have to wonder whether a problem occurs due to the driver, the database, or our request.
Unit tests do not help us with edge cases and situations we didn't predict. In software, there is no such thing as "getting it right". There's only getting something to pass the tests. Tests can be flawed and necessarily are incomplete. As a result, bugs will occur. Ignoring that fact, caused by a misplaced belief in the infallibility of unit tests, has been shown a fallacy.
The way to battle bugs effectively, is to reduce the system complexity, and to train your programmers. If necessary, throw it out and start over.
Be relentless.
I understand that can be difficult. It hurts our pride to throw out something that cost us a lot of time and effort, something that made us proud. But it its complexity makes it too hard to debug, dump it, learn from it, and make yourself even more proud.
Need problem solving?
Talk to me. Let's meet for coffee or over lunch. Mail me at “omegajunior at protonmail dot com”.