Naturally we can find a library shelf full with books on software design, quality, and testing. What I’m presenting below is just a little note on the subject. I feel like preaching a little today…(^_^)
The thinking exercise last week, to envision yourself as a chocolate factory owner and as a software freelancer, had several goals behind it:
- To get into an unknown industry an analyze their way of work, their entire business. As you go from junior developer to the next stage, what counts next is not so much your ability to write useful and functional software (that’s already assumed to be there), but to get into the details of a particular industry quickly. Math and computers have in common that they have little use on their own. You have to apply them somewhere to make them useful; hence, software developers who don’t have practical (hands-on) industry knowledge in a particular industry, will have difficulty entering it. For example, if you worked in the automotive industry as a developer, you can’t easily switch to the insurance and banking industry. They all prefer that you have already worked on their turf for a while so they don’t have to teach you their basics, which can be a 4-year study of its own. Trying to see the world from the chocolate factory owners view is not so easy when you don’t work in that business. That’s exactly the point of the exercise! In order to get hired in a new industry you need the ability to absorb industry details quickly, which requires a certain attitude towards new things. A useful attitude to have is “I want to know everything,”…. 🙂
- To discover quality principles in a nutshell as they relate to software. As a great software professional you look always at new problems with a fresh perspective. You don’t think you have done this before even if you sort of did. You did some work before, you have some components you are familiar with that you could re-use, you talk to as many people as possible to get all details into your head. Whenever you think you figured it all out, you smack yourself in the face and tell yourself ‘don’t jump to unfounded conclusions…’ You double and triple-check everything. Your psychologist thought you were paranoid and obsessive compulsive, until she finally figured out you are an engineer. Before you type anything, you draw several plans on paper or a board and discuss your ideas with others and then decide to trash them. You try to be as ‘negative’ as possible with your plans in order to find something that’s missing. Something you forgot, that would break the ‘system’, the plan you have in mind. You look for it because you know it’s there but you can’t see it (remember you are paranoid after all…)
- Once the plan makes sense (and there usually is no such thing as a final plan), and it covers all the bits and pieces you have gathered, every single requirement, you decide not to start. You think about tomorrow’s requirements. What is likely going to be tomorrow’s problem?
- If you write software for a client, it’s likely your client is not an IT guy and doesn’t know what s/he needs exactly. Also, because you are an “information pro” you need to break down and conceptualize your client’s data and processes so they fit neatly into the system you are creating.
- If your system interfaces with other software you need to closely inspect those interfaces. They likely will be a source of headaches. Having worked in the business for years you have developed a feel for what bug you will likely encounter with other people’s code. You have started to anticipate the devil (who is in the details and) is always around the corner… Also you need to make predictions about how these interfaces are likely to change over time and be already prepared for those potential changes.
- Break down each component into steps. If it fits it ships they say at the USPS. A piece of code (a function) has to fit on one screen or it’s too long. Just like the chocolate factory separated everything into small production steps, you also split everything into sub-functions. Every procedure you write receives inputs and creates outputs. In between, it does something. Every procedure needs an input barrier and an output barrier. Ideally no invalid signals enter undetected and undefined results ever come out without an error signal of some sort. Everything that occurs inside each procedure is logged in a log file (or use related mechanism). Every single operation needs to be checked, even, for example, a + b, because it could result in an overflow. When you split a large process into small pieces, think about clarity and above all “code reuse”. Number #3 is the holy grail of software development. Early adopters of this methodology became productive faster and succeeded at every software project.
- Only a small percentage of software ‘gurus’ out there are doing all of the above religiously, and they happen to be the most productive. In every company, large or small, there are a handful of these guys effectively running the entire shop. It is the ‘secret’ sauce to a 10-fold productivity and more. When you read about ‘star programmers’ and that they work like 10 or 20 developers combined (and work less than 8h/day), they do pretty much what is outlined above. It’s not a phenomenal talent, it’s just disciplined engineering. Naturally foreseeing all future problems and making code super-robust are ideals, but there is little doubt that the closer you get to such a design, the more productive and effective you become. A lot of the productivity originates from having prepared, just like a chef in the kitchen prepares his ingredients ahead of time, reliable and immediately reusable building blocks. It’s because the remainder of all software people are spending 95% of their time ‘debugging’, only to find out their spaghetti solution isn’t working and it’s definitely not solving the problem at hand. What happens then in a typical project is that more people are added to a late project and surprisingly it is then delayed even more because even more people are now busy looking for errors instead of developing more code. Or, they finally solve the problem at hand after weeks of debugging but need to trash all the code tomorrow because of that “one little new thing” that management will ask for tomorrow and that can’t be accommodated without dramatic changes to the source code.