Some things are constant over time.<\/p>\n\n\n\n
Many of the fundamental principles of problem solving and software development always matter at some level. Many of the hardest problems you will need to solve are related to fundamentals that you should already know.<\/p>\n\n\n\n
Some of the details change. When I started programming, amount of available memory was something that you needed to watch constantly. (When you have less than a megabyte of system memory, you can’t use memory indiscriminately.) In the present, many programs can ignore quite a bit of memory usage, as long as your memory use is actually bounded.<\/p>\n\n\n\n
Access times still matter. Systems have multiple levels of caching to keep main memory access from being much of a bottleneck. Accessing disk is still much, much slower. The same holds true for network access.<\/p>\n\n\n\n
Data structures and algorithms are still more important than micro-optimizations. Computational complexity still matters. With the speed of current systems and the amount of memory available, you can ignore the fundamentals a little longer, but they will still jump up and bite you if you ignore them for too long.<\/p>\n\n\n\n
Adding security after the software is complete is much harder than thinking about those issues ahead of time. It is possible to add layers of protection after the fact. Many commercial products and open source products have done just that. But, the result is normally buggier and less secure than it would be with a little thought.<\/p>\n\n\n\n
Validating inputs, the Need to Know<\/a> principle, the Principle of Least Privilege<\/a>, good authentication, auditing capability (for both access tracking and non-repudiation) are all important at different levels in different programs. Considering these early in the development process makes reasoning about security and threat modeling much easier to get right.<\/p>\n\n\n\n Once the software is complete, it practically<\/em> impossible to significantly improve the quality. While not actually impossible, it requires a huge investment in time and effort.<\/p>\n\n\n\n Almost every experienced developer has had a case where a quick-and-dirty program was built to test an idea (either an official prototype or just a one-off experiment), and was then rushed into production. As an experiment, these kinds of programs are usually light on the kinds of quality and reliability concerns that should be part of production code. That’s fine for an experiment. Once this experiment is in production, you need to upgrade the program to be robust and reliable.<\/p>\n\n\n\n That kind of quality takes time. Unfortunately, adding quality to the code will be harder, because the short-cuts that came as part of a quick prototype will often have far reaching effects. Unwinding those decisions will not be trivial. (Using a concept from medicine, the longer a shortcut is in the code, the more likely it is to metastasize. Assumptions related to that shortcut will apply in other parts of the code. The shortcut will be duplicated elsewhere. Some of these decisions will be implicit in the code, and hard to discover. Finding and fixing these implicit changes will be a major effort.)<\/p>\n\n\n\n For example, if you are running a program locally, crashing because of bad input is not a big issue. You can correct your input and run it again. Security is not a big issue, since you know your access and don’t need to segregate functionality for different kinds of users. If you are the only user, it is unlikely that you will use the code to attack yourself. Output doesn’t need to be scrutinized too closely, since you are the only one to see it.<\/p>\n\n\n\n All of these decisions affect numerous small design decisions made while writing the code. As you try to fix one problem (say authorization), you may discover that your code does not properly deal with multiple levels of authorization. This leads to the realization that you must configure different parts of the code with different authorization levels. That brings up how you need to handle authorization failures. How do those failures that affect logging? Will the displayed output be different at different levels? (Is it just display everything or nothing? Do we need to redact part of the data for some authorization levels? How do we track those levels for auditing purposes?)<\/p>\n\n\n\n Fixing some design decisions will show other decisions that need to be re-considered. Some of those changes may feed back to decisions that you thought were fine. And so on.<\/p>\n\n\n\n One of the most critical constants in software is the need to validate every input that comes from outside your software. This includes environment variables, files you read, data from databases, inputs from the user or other systems. Everything is suspect. At a minimum, you need to validate that any incoming data is of a proper form and type. While avoiding this kind of validation can make the initial work on the code seem faster, you are just setting yourself up for failures ranging from corrupted data to major security flaws, edge cases, and hard to find bugs.<\/p>\n\n\n\n One side effect of not validating data on input is the need to re-check data at different points within the system. Since data was not guaranteed to be valid initially, you will need to deal with the possibility that the data is not valid when you go to use the data. If the data is actually valid, you are wasting resources re-validating multiple times. If the data is only possibly valid, you need to make certain that data is validated before each use, otherwise errors can result.<\/p>\n\n\n\n A strong type system with types defined to be valid can make it possible to only use valid data, but that is not always possible in all languages\/environments.<\/p>\n\n\n\n Sometimes the old truisms no longer apply. The fact that these change is actually a constant factor in software. New languages, paradigms, methodologies, hardware, etc. are always coming along.<\/p>\n\n\n\n Some of these changes will make a real difference in the field, many of them won’t. It isn’t always possible to tell which changes will last and which ones will fade. Consequently, you can’t necessarily tell ahead of time which changes you need to ignore and which you will need to embrace.<\/p>\n\n\n\n In my experience, you need to be skeptical of any amazing<\/em> solution that you can only get from a company that wants to make money off of you. Many of those have turned out to be hype in the past. Anything that claims to solve all of your problems, with no downsides or side effects are also likely to be avoidable. After all, we’ve known since the 1970s, that there are no silver bullets<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Some things are constant over time. Fundamentals Always Matter Many of the fundamental principles of problem solving and software development always matter at some level. Many of the hardest problems you will need to solve are related to fundamentals that you should already know. Some of the details change. When I started programming, amount of\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,6,17,18],"tags":[89,106,147,411],"class_list":["post-1467","post","type-post","status-publish","format-standard","hentry","category-architecture","category-codecraft","category-production-software","category-programming-philosophy","tag-constants","tag-design","tag-fundamentals","tag-technology"],"_links":{"self":[{"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/posts\/1467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/comments?post=1467"}],"version-history":[{"count":5,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/posts\/1467\/revisions"}],"predecessor-version":[{"id":1473,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/posts\/1467\/revisions\/1473"}],"wp:attachment":[{"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/media?parent=1467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/categories?post=1467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.gwadej.org\/programmer-musings\/wp-json\/wp\/v2\/tags?post=1467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}It is Almost Impossible to Bolt on Quality<\/h2>\n\n\n\n
Validate All Input<\/h2>\n\n\n\n
Technology and Industry Changes<\/h2>\n\n\n\n