A Person, Artist, Software Engineer, Geologist.

When do I know it's time to refactor code? Refactoring is different for every person but for me I follow these guidelines: - If I don't know / understand the code, I don't refactor.  Period! - Is the code broken?  If not then I generally don't refactor - Can the code be made much simpler?  If the amount of code can be reduced by 2x and made cleaner / simpler then I may refactor. - Can the existing code handle the new feature / bug fix?  If not then I may refactor. - I will not refactor the code if I think I have a better way.  Better my be for me but not other developers.  I leave working code working. Tests: I never assume that tests for existing code: -  Has complete code coverage (I've never seen this yet).  I've seen 100% coverage but not all combinations of logic or possible side effects of API changes, etc. - That the tests are even correct.  The tests only test what the developer wanted to test, not what could / should happen.  Tests are neve

My thinking toolbox consists of the thoughts that I have when designing and coding.  At a base level what I am concerned about is basically: Will this solve the issue? With others understand this? Can it be maintained and modified? Does this suit the issue? How can this effect other code or other developers? No matter what one does, whether one's deeds serve virtue or vice, nothing lacks importance. All actions bear a kind of fruit. - Buddha  Nothing that we do is without side effects and development is no different.  When a piece of code is designed or written, does it belong to the engineer that wrote it?  Will it ever effect anyone else?  How and why code is written can have far reaching effects down stream of it's creation. One of my concerns for any code that I write is if others can understand it.  My test for this is: Is the code the right complexity for the issue at hand.   Are there any hidden levels of indirection (think reflection, property files, re

From "Buddhist thought of the day" comes this quote: When you give a shilling to a beggar - do you realize that you are giving it to yourself? When you help a lame dog over a stile - do you realize that you yourself are being helped? When you kick a man when he is down - do you realize that you are kicking yourself? Give him another kick - if you deserve it! - Why Lazurus Laughed by Wei Wu Wei... My variation of this theme (because I'm a simple person) is this: Code spends most of it's life being enhanced and maintained by developers other that the original creator.  It should be clear. If it's hard to understand by the next programmer, they are more likely to re-design / re-write it and create new and different bugs. Don't try to show others how smart you are, just make their (and your) life easier.  You will gain new friends and like yourself better. Try to separate the what needs to be done from how it's being done.  This is a defining pillar

I got a new camera recently and am enjoying it.  Yeah it's cool (a Nikon D3000) but that is not the reason I enjoy it.  I enjoy it because it shows things for what they are.  Let me explain. First of all, I'm not that great of photographer but I enjoy looking at pretty things and the camera forces me to take time to do so.  The other thing that camera's do is not being subjective.  When a picture is taken, it is what it is.  It does not place a narrative overtone of what you are seeing, it just shows you the facts. Which brings us to how this is related to software engineering. In any meeting or discussion that occurs with software engineers about technology, design or technique, it's can be difficult to determine what are "facts" about an issue from the different versions of "truth" from engineers.  Truth is not the same as facts, facts don't change.  The sun rises every morning but the truth of why the sun rises may change with culture an

I can't say what code makes you happy but I can tell what code makes me happy. My greatest satisfaction is from : Getting things done (documents, features, working with people, etc). Understanding / learning how a specific framework, library or tool ready works. Visualizing how and why a design works or does not work. A while back I had a couple of very pleasurable moments working with some code.  One moment was working with the Java Swing GUI Library and the other was in a design pattern that was a variation of MVC (Model View Controller), or so I thought. I was working with the Java Swing library trying to get a panel contained in a JScrollPane to set the scroll bar at the top of the viewport.  For a normal panel this is a piece of cake but not when the panels components are dynamically added to the panel after it's made visible.  What made me happy about this task was that it forced me to think of not what I wanted to do but what was really happening inside the lib

It's not that your way is not the right way, it's that everyone has their own right way.  So which is the right way?  Is there a right way? Software development is full of discussions that revolve about the "right" way of doing something. The terms used in discussing software design, tools and implementation are so undefined as to make them meaningless.  Code is not designed and written in a vacuum, it's designed by real people in real companies, each with their own constraints and issues.  Code that may look like a hack could have been the result of an employee dragged out of bed at 2am by a company shirt that only cared that they they did not lose their personal client the next morning.  Everything must be looked at in context.  A project written to "Best Practices" may never be finished before development funding dries up.   Goals, vision, constraints and thoughts should be somewhat aligned for project to be successful (or at least enjoyable in deve

If you have been in the software development business for any length of time you will see strong emotions expressed (by yourself or others).  Being on the emotional side of this for many years, it finally came to a head for me.  This caused me to re-evaluate my self from a Buddhist perspective of how I developed software and how I though of myself and others.  Well not really so much about software but how I though about my self and what I was thinking.  I needed to de-couple my thoughts, desires and goals from the tasks at hand and learn.  I likened this to an out of body experience to evaluate how I was thinking and what was happening around me while not getting involved. Very insightful this was. I must have spent a couple of years just watching, looking and understanding what was going on around me and how my thoughts could contribute to the benefit or determent of whatever situation is at hand.  I needed to, and had started taking myself out of the equation.  By doing this I