Software principles are useful tools for design and implementation and they help us produce quality products. However, software principles can be compromised at times. They don't always have to be followed as there are exceptions to the rule. In some ways, they are similar to some life principles, and this blog explores that idea.
Software and Life
In life we have ethics and morals that we live by. Ethics and morals manifest themselves as life principles. They give us a framework to become better people, respect one another, and ultimately improve our quality of life.
In the software industry we have software design principles. They are rules we operate under in order to make the products we develop elegant, easy to understand, and maintainable. Software products run our economy or make our day to day lives easier, and software principles play a large role in allowing that to happen.
However, software design principles are not meant to be dogmatic. They are not meant to be strictly adhered to. The use of software principles should be evaluated within the prism of trade offs. Software principles are essentially rules of thumbs and can be broken if it's the most pragmatic thing to do.
Software principles are like some life principles . . . but unlike others. To illustrate my point, let's consider some life principles that can be considered absolute, i.e, should never be broken no matter what the circumstances.
Don't Cheat, and Be Nice
Take the rule "Don't cheat." Under no circumstances would I teach my son that it is permissible to cheat. It's not OK to cheat on a test at school. It's not OK to cheat on your taxes, and its not OK to cheat on a board game at home. No matter what the context, big or small, cheating is not beneficial. It only hurts others and ultimately your self. Software principles aren't like the cheating principle.
Another example would be "Never treat a person as a means to an end." It is unethical to use a person strictly as a means to an end with disregard to their humanity. People should be treated as human beings, not as objects. Under no circumstances, would I teach my child to "use" someone just for the sake of personal gain and devoid of respect. Software principles aren't like ethical principles . . . we can break them if needed.
So what are software principles like then, and what software principles am I talking about? Most life principles we live by are general rules of thumb, they are not absolutes. Software principles are like that. Here are a few examples of what I mean:
DRY
We live by the principle of "Always tell the truth", but this rule doesn't always apply. Take for example white lies. If your wife asks you, "Do I look fat in this dress?", you would be asinine to say yes. Most us would say "No honey, you look great!" Even though your beautiful wife may be slightly overweight (no big deal in my eyes, personally.)
In software, we have the DRY principle: Don't Repeat Yourself. This should be something you mostly do and can greatly contribute to clean code. But would you really want to create a full fledged Template or Strategy Method Pattern to save 1 or 2 lines of code? Sometimes violating the DRY principle can avoid excessive pattern usage, which can cripple a project and make code unintelligible. Evaluate the trade offs for DRY and make the best decision.
Law Of Demeter
How about the life principle of "Always eat healthy"? Yes, we should eat healthy and watch our diet, in general, so we can live a quality life. But we are allowed to break the rule on holidays and eat the fried turkey and pecan pie. It is permissible to go out with the guys and down some beers and wings once in a while. It's not going to kill you. If eating unhealthy is the exception, it is fine.
The Law of Demeter is a software principle that enables loose coupling and limits the knowledge of one component to another. Following this rule keeps your code understandable and limits dependencies. But even though its called a "law", it should be viewed more as a guideline. If you are dealing with an anemic object, and just need to get some data, it is permissible to for a client to dig through objects to get what it needs. The alternative would be to blow up the API with several needless methods, which is a documented disadvantage of Law of Demeter.
Conclusion
When designing software, we should understand that software principles should be followed in order to produce quality code. However, use them in a pragmatic manner and don't pursue a software principle so hard that it makes your life and code, miserable. Evaluate your design in terms of trade offs. After all, we certainly have life principles that we don't always follow, and software principles are the same way. Do what's best for value added effort and leave the dogma behind.
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts
Wednesday, July 21, 2010
Monday, March 22, 2010
5 Ways to Think Wisely in Development
Recently I have been reading some popular and interesting social psychology books. The contents are based on empirical evidence and scientific research, and often provide stories about how society operates, and why people behave the way they do. Some of the books in this genre include: Freakonomics, The Tipping Point, Outliers and Kluge
The most recent book I read is Kluge: The Haphazard Construction of the Human Mind, by Gary Marcus. Marcus argues that the human mind is not the elegantly designed organ that we conventionally perceive it as, rather it is a cobbled together contraption which is a product of evolution. He offers explanations on why our minds do clumsy things, such as forget where our car is parked, or why we can't remember what we ate for breakfast.
Without getting into the details, he points out several characteristics of the human brain that are products of evolution. Our cognitive makeup contains several bugs which can be referenced by psychological terms, some of which include: context driven memory, confirmation bias, motivated reasoning, and framing. (I'll leave the explanation of these terms to the book itself.) He also gives recommendations on how to overcome these mental pitfalls. It is a fascinating for the laymen psychologist.
So what does all this have to do with developing software? From Marcus' exploration of the mind, I see several recommendations that can help us become better software developers. Many of the technical and social decisions we make as part of a software team are often afflicted by the "kluges" of the mind. Some basic and common sense tactics can help offset these imperfections, not to mention a help us becomes clearer thinkers, wiser developers, and better teammates.
1. When possible, consider alternative hypotheses.
Often when we have an idea, we get stuck on it and want to see it through to the finish, just for the satisfaction of feeling good about ourselves. It could be a design pattern we see for a problem, or it could be some performance enhancement we think needs done. We tend to not evaluate our own ideas in a dispassionate or objective way. One of the simplest things we can do to improve our capacity to think and come up with good solutions is to consider an alternative track. Contemplate on the opposite and counter your own initial ideas. This can go a long way on improving your own initial thoughts or could lead to an entirely better solution.
2. Imagine your decisions will be spot-checked.
Research has shown that people who believe that they will have to justify their answers are less biased than people who don't. Hold yourself accountable for any decisions you make, technical or otherwise. If we do this, we will tend to invest more cognitive effort and make correspondingly better decisions based on analysis, not just feelings or habits. A good practice would be to write down rationale for any sophisticated decision made and make sure the reasoning is sound. This could be notes for yourself, or published to the software team in a collaborative tool such as a wiki.
3. Always weigh benefits against costs.
There is always some feature or tool that is cool to use or enticing to learn. We should always weigh the benefits versus the costs before we proceed down a certain route. The feature may be cool to the developers, but how much business value does it provide? Does it help the business save money? The new ORM tool looks great and has some added benefits, but what cost will it incur versus the technical savings?
The inverse argument should be considered just as much. A refactoring may incur some cost to implement upfront, but will payoff in the long run by resulting in more maintainable and defect free code. The new integration testing tool may require a week of investment, but could reap dividends by allowing the team to write automated tests and eliminate the painstaking manual and repeated tests. Sometimes the initial pain is worth enduring to get a long term benefit.
4. Whenever possible, don't make important decisions when you are tired or have other things on your mind.
Marcus describes how we have two portions of the brain: the reflexive and the deliberative. The reflexive portion of the brain evolved early on and controls our bodily motions. It also controls ours emotions and fight or flight responses. The deliberative portion of the brain is the most recently evolved and controls rational thinking and logic.
When making decisions related to software, make sure you are well rested and not stressed. Get enough sleep and keep your hunger under control. When your health is not optimal, your reflexive portion of the brain activates and overrides the rational part. This inhibits rational thinking and can especially inhibit complicated problem solving. In order to make the best technical and team decisions, keep in a rested state to leverage the rational part of the mind.
5. Distance yourself.
Our mind is set up to ponder the near and defer future decisions for a later time. It's always about the now and the urgency of the present. The release needs to be done immediately, and we get into fire fighter mode where everything is an emergency. Or...The debate is on about the new design and we must engage in the battle and win the argument!
It's always best to take a step back and distance yourself from the situation. Imagine you are watching from afar and try to judge the situation objectively. Of course, the here and now is always important, but it's also important to balance situation by distancing yourself. Doing so will help assess the situation fairly. It can also let the reflexive portion of the brain simmer down and let the deliberative mind step in to take control when needed.
Even though we are rational people in a technical field, we are human after all. We are products of our ancestors and emotions and rationality are both part of our makeup, although not always in the correct proportion. However, simple mindful steps can be taken to offset any shortcomings we have.
The most recent book I read is Kluge: The Haphazard Construction of the Human Mind, by Gary Marcus. Marcus argues that the human mind is not the elegantly designed organ that we conventionally perceive it as, rather it is a cobbled together contraption which is a product of evolution. He offers explanations on why our minds do clumsy things, such as forget where our car is parked, or why we can't remember what we ate for breakfast.
Without getting into the details, he points out several characteristics of the human brain that are products of evolution. Our cognitive makeup contains several bugs which can be referenced by psychological terms, some of which include: context driven memory, confirmation bias, motivated reasoning, and framing. (I'll leave the explanation of these terms to the book itself.) He also gives recommendations on how to overcome these mental pitfalls. It is a fascinating for the laymen psychologist.
So what does all this have to do with developing software? From Marcus' exploration of the mind, I see several recommendations that can help us become better software developers. Many of the technical and social decisions we make as part of a software team are often afflicted by the "kluges" of the mind. Some basic and common sense tactics can help offset these imperfections, not to mention a help us becomes clearer thinkers, wiser developers, and better teammates.
1. When possible, consider alternative hypotheses.
Often when we have an idea, we get stuck on it and want to see it through to the finish, just for the satisfaction of feeling good about ourselves. It could be a design pattern we see for a problem, or it could be some performance enhancement we think needs done. We tend to not evaluate our own ideas in a dispassionate or objective way. One of the simplest things we can do to improve our capacity to think and come up with good solutions is to consider an alternative track. Contemplate on the opposite and counter your own initial ideas. This can go a long way on improving your own initial thoughts or could lead to an entirely better solution.
2. Imagine your decisions will be spot-checked.
Research has shown that people who believe that they will have to justify their answers are less biased than people who don't. Hold yourself accountable for any decisions you make, technical or otherwise. If we do this, we will tend to invest more cognitive effort and make correspondingly better decisions based on analysis, not just feelings or habits. A good practice would be to write down rationale for any sophisticated decision made and make sure the reasoning is sound. This could be notes for yourself, or published to the software team in a collaborative tool such as a wiki.
3. Always weigh benefits against costs.
There is always some feature or tool that is cool to use or enticing to learn. We should always weigh the benefits versus the costs before we proceed down a certain route. The feature may be cool to the developers, but how much business value does it provide? Does it help the business save money? The new ORM tool looks great and has some added benefits, but what cost will it incur versus the technical savings?
The inverse argument should be considered just as much. A refactoring may incur some cost to implement upfront, but will payoff in the long run by resulting in more maintainable and defect free code. The new integration testing tool may require a week of investment, but could reap dividends by allowing the team to write automated tests and eliminate the painstaking manual and repeated tests. Sometimes the initial pain is worth enduring to get a long term benefit.
4. Whenever possible, don't make important decisions when you are tired or have other things on your mind.
Marcus describes how we have two portions of the brain: the reflexive and the deliberative. The reflexive portion of the brain evolved early on and controls our bodily motions. It also controls ours emotions and fight or flight responses. The deliberative portion of the brain is the most recently evolved and controls rational thinking and logic.
When making decisions related to software, make sure you are well rested and not stressed. Get enough sleep and keep your hunger under control. When your health is not optimal, your reflexive portion of the brain activates and overrides the rational part. This inhibits rational thinking and can especially inhibit complicated problem solving. In order to make the best technical and team decisions, keep in a rested state to leverage the rational part of the mind.
5. Distance yourself.
Our mind is set up to ponder the near and defer future decisions for a later time. It's always about the now and the urgency of the present. The release needs to be done immediately, and we get into fire fighter mode where everything is an emergency. Or...The debate is on about the new design and we must engage in the battle and win the argument!
It's always best to take a step back and distance yourself from the situation. Imagine you are watching from afar and try to judge the situation objectively. Of course, the here and now is always important, but it's also important to balance situation by distancing yourself. Doing so will help assess the situation fairly. It can also let the reflexive portion of the brain simmer down and let the deliberative mind step in to take control when needed.
Even though we are rational people in a technical field, we are human after all. We are products of our ancestors and emotions and rationality are both part of our makeup, although not always in the correct proportion. However, simple mindful steps can be taken to offset any shortcomings we have.
Subscribe to:
Posts (Atom)