When does automating test worth doing and when it does not? one of the consideration I think the is volatility of the code.
The more volatile the code the more it is probably not worth automating, at least not directly. If you just code something to be changed not long after or will be changed quite frequently keeping it automatically tested will be costly. It is not a burden if it is only several dynamic part that we tested, but if there is a lot of them the accumulation of little frequently-changing tests that need to be maintained will be burdensome.
I know, if you use TestDrivenDevelopment, you make test first before any code. However, I think of it in conceptual level. You have to have test before any code, not to have The Test e.g: xUnit-based test. Your test could be in your mind and the value could be the one that your command line program print in console and you do Assert with the value in your mind. It's TestDriven enough for me and for not yet stable problem sometime I feel it's more flexible that way.
My concern here is on the word "automating" not on the TestDriven-ness. Automation is investment and it should be managed so that it gives us benefit more than it cost. Volatile code makes the tests volatile too, so lots of volatile code to test, lost of cost in changing/maintaining those test accumulatively.
There are a lot of solution for this e.g: test it indirectly through more stable code, but the main point is that we could test in a more efficient manner by paying attention to volatility of the code.
Thursday, January 31, 2008
When does automating test worth doing and when it does not? one of the consideration I think the is volatility of the code.
Wednesday, January 30, 2008
Regarding Coding Standard, Instead of following something resembling Coding Standard I see what I have been doing lately is more of from the other way direction : Coding Tolerance. With standard, you define what you want and then define how things should be to meet those. With coding tolerance you start with let things be the way they are and then review what you can tolerate and do refinement when necessary.
Coding Tolerance can be looked as a bottom-up, pragmatic approach to making guidelines in coding. With it, you do not spend time in advance to try to cover all possible things that would mess things up. Instead you allow codes to contribute as long as you can still tolerate it based on your knowledge, experience, situation and condition you try to maintain steady progress.
Tolerating does not mean you start with zero rules. You define only small, substantial guideline at the beginning and refine from there case by case, item by item and refactor/streamline the rules when necessary. You don't judge the code from your coworker or from certain libraries by rigid syntaxtual standard, instead you try to understand why they got the way they are and whether you can still accept it considering your goal. There are many learning experience you'll get from it.
The insights we get from tolerating certain coding style is not just we can go relatively faster in short term (since we focus on getting things working), but it is beneficial for the future too. We could get insights on better way of doing things that we will not get if we just forcing insisting that our way is the right way.
So, the next time you try to define coding standard, try to define it from the perspective of what you can tolerate instead of the usual structure, style, syntax oriented rule. It might give you lighter, easier rule to comply that is still effective.
Tuesday, January 29, 2008
Programmers has two hat that he can switch around to avoid blocking when coding. Those two are the Analytical (thinking, elaborating and tracing logic) and Empirical hat (Debug, print and compare values). Without being aware of this, I find that I sometime spend too much time in one mode that if I just switch to another mode when things seems getting hopeless in the current mode it could be a lot faster. Being flexible in switching mode could speed up and ease up the problem solving process. It'll make things more fun too, almost like playing a game.
Being Analytical is when you review the structure and logic of program, class design, association, hierarchies, call sequence and finally find out what to do. Being Empirical is just give the program the input, trace, see the real numbers and values, and review the output.
Blocking in analytical mode is when you find reviewing the structure and logic seems to get you nowhere, the class seems ok, the function and logic looks alright but the output is wrong. Blocking in empirical is when the input and output does not reveal to you any pattern on insights on what's going on.
Our brain seems to need both concrete/empirical and conceptual input in problem solving. The empirical test could help us understand part of the logic that might not get into our attention when relying only on static analyzing. The analytical view could shed us some lights on the problems in it's substantial level that the output fail to give us any concrete things to work on.
In coding, when reviewing why something does not work, I usually start with analytical review and if it's not solving anything, I just start tracing, dumping values, debugging. Sometime in the middle of tracing and debugging I got another idea to review certain part analytically. I just need to remember not to push to solve the problem in one mode if it does not seen to bear fruit and start to see it with another perspective.
Of course, when both are fail, taking a break would probably the best thing to do. But that's another issue and would require another discussion. The point is to avoid being sucked by the problem and utilize different perspective to keep things in control and most importantly, to keep it fun.
Thursday, January 24, 2008
On the book "Agile Software Development", Alistair Cockburn wrote that there are two game running in parallel when people develop software. The two game can be summarized as :
- Make code that work
- Keep the code workable
I see the two item above parallel with, if not an instance of, the concept of Production/ProductionCapacity (P/PC) balance in Stephen Covey's book "Seven Habit of Highly Effective People". And if you look around for more, many problem following the same model : using tool vs. learning the new ones, adding more hours in one language with experimenting with the new ones.
Defining Effectivity as balancing between P/PC is like defining EffectiveCoding as balancing between Coding/Refactoring.
Wednesday, January 23, 2008
I've mentioned in the previous post that I used Mindmapping application to track my internet search in realtime. The reason is that the search can go out of hand if not tracked like this. We could end up spending hours looking at anything that caught our attention on the search result that is not too relevant to our current task.
Here's how, more or less, my "control center" looks like when I do a research-heavy task :
You've probably guessed the convention already : red for active item, green for done, small gray on notes.
I think the next step for after having a taste of how the searching in internet done and what it can gives us, is to use it with some kind of heuristic and a little discipline. This is just my current way of doing it and I find it quite useful to help focus on getting things done.
Monday, January 21, 2008
There cases where C is chosen as a programming language. When this happen, I think it's better to use C++ with C style programming instead of using "classical" style one. This means use C++ as a Better C, an improved C for functional programming without it's Object Oriented and Generic Programming.
I have seen the code written in recent times that still use C strictly with it's old convention and. I think it's still makes sense if it's a maintenance/bug fixing work, but for new project I think we could improve readability, safety and more convenient coding time.
You could choose to use feature that only improve your typically-used structure like inline function to replace macro or use flexible declaration placement instead of having to declare all of them in the beginning. If you feel brave enough you could use more new stuff like references. You could even use STL's containers without harming your program's "functional-ness" (just use typedefs to hide those nasty template instantiation).
As a guideline, don't use what you don't understand or only have a vague sense of why behind certain construct. When you do, you'll most likely will get into trouble sooner or later.
You could program in functional-paradigm without having to revert to use plain old C these days, just need to get a little familiar with what C++ has to offer regarding it.
Thursday, January 17, 2008
One useful idea in GTD is to separate collection and followup/action step. It helps us to not caught up in reactive mode and loose sense of direction. I find this idea really useful when I do searching on the internet. It is even more critical in this matter since there are tons of things that could get you off-balance and distracted while searching things on the net.
First thing to do is to have map and tracking tools of what you need to do. It can be just your mind, but it's better to have helper tools like Text Editor or Minmapping application. Be clear on what you want and put an entry on each query you requested and track what you get from each. Jotting down the query you pass and track the result of each can be a useful trick to incrementally refine your search. The next is to do it in two separate steps : collection and action.
In collection step I only skim each of the links or page and drag them to to bookmark and/or scrapbook (see my post on setup firefox for this purpose). Along the way, when I find any unrelated but seems interesting I just drag them to tmp folder to followup sometime later when there's more free time. Then, when I think I have enough interesting things and the search result seems exhausted I continue with action step i.e: follow them up one by one in a more relax and more concentration on each.
I don't always do it in a clear separation or perfectly like the above, there's occasional time I just follow along with the chain of links. However, having mentally separate the process helps to get more of the links i.e: prioritize which to followup and avoid to get distracted. If we just get along, we might already exhausted and our mind distracted when we unconsciously missed a worthy one or don't have energy to followup anymore links ahead which could have a good info.
Internet is such a big source of distraction if you are not careful. But it will be a dependable servant when you have clear focus on what you want and structure and discipline in handling what it gives back to you. Of course, it's fun to surf for leisure but it's better not to do it at the time you intended to have something done.
Tuesday, January 15, 2008
Reading books is reading filtered and structured knowledge. Compare to other sources like news, articles, forums, it has relatively the highest signal to noise ratio. That value comes with a cost, most notably generalization and omission of some details and context-related materials. Relative to other more "real-time" sources it is more "sterile".
This is why when we read books we feel we got so much information but sometime we are left hanging when trying to implement it in our situation. It's because the details in books are already smoothen out, some parts are simplified, so it is up to the reader to put them back on the reality ground. If I am going to write about some new techniques I would not have enough space to cover all possible cases but only take that I think would be enough to inspire and make a point to the reader.
There's nothing wrong with it, of course. It's just how the books are positioned and made. It's the forums, mailing lists, discussion group and our own experience role to fill in the blank. Besides, it's where the fun lies anyway.
Monday, January 14, 2008
Using boost::shared_ptr in the typical situation is quite straightforward. If what you want is to to have your use of new and delete conforms with RAII idiom you will find it as close as coding things in language like Java. However when you need to use it beyond object that is acquired/instantiated the typical way e.g: COM object, it's when you find it's not that obvious.
It's quite simple actually but the standard documentation can be quite confusing if what you want to find is a practical way to do it. I find this discussion shed a light to this issue quite clearly.
It turn out that what you need to do is
- make a custom deallocator function that takes pointer to the class
- pass the function name as the second parameter to the shared_ptr's constructor
2:void deallocatorFunc(ClassA *p)
4: //deallocate p
7:boost::shared_ptr< ClassA > ptr(new ClassA(), deallocatorFunc);
Thursday, January 10, 2008
People debated over believes, religion, OS, text editor. Many times it's fun but a lot of them unnecessary. We could actually simplify things by being really clear on what we need and expect.
We could end up with debates and confusion when we are not really have one specific things in mind ourselves. We prolong problems by searching in in elegance side while we are really prioritizing functionality, picky about the price while our constraint is really about time, worry about perfection while anything good enough is more than enough to get us going. We stumble upon a fight over people regarding ideology in the process of searching very simple practical things.
We could simplify more by being really clear too about what the other people intention and perspective. We rarely have to be in defensive position when we realize clearly where the other people stand, if at all. People usually have a good point if we know what perspective they use and the background they have.
When we end up trying something we could also save time when we are clear what to use it for. For example, we don't bother checking out the internals of the lib if the part that we use it works perfectly well for our purpose. We only need those part functional and don't care about the rest.
So, be it religion, methodology, tools, libraries, framework. Being clear is a good filters and heuristic to get things that works for us. We'll also save more time that we could use to extract values on whatever we finally choose.
As a final note: sometime just trying things save hours of debating, it also sometimes give us valuable insights that won't come out just by debating, wondering or worrying.
Monday, January 07, 2008
The greatest lesson of learning a lot of stuff, trying tools and concepts are not on how it actually solve our problem but, I guess, is on this : It teach us that people and problem are unique and there's no one single tool/solution that can cover all and it's better to have something that is modular, customizable and adaptive.
Even before we start to implement something new we'll probably already see how it has some edges and parts that does not really mirror with our situation. We then pick some part that is useful and left or modify the one that does not.
Learning from this picking and modification, I think a good tools and concept is the one that is more modular and flexible. People prefer to use something modular and flexible to something that requite "All or nothing" approach. It enable people to adapt it more to their situation.
However, for concept and methodology, this modular, toolbox-based approach is also necessary in learning and adapting new things. The tools and concept should enter into our toolbox and not hijack our mind. We should only let inside something that can be a good citizen in our mind i.e: helpful but not destroy our mind flexibility. Intrusive tools and concept should be avoided, or if it's not avoidable should be allowed with care.
This could explain why many people like the concept of plugins or interdependent little tools in UNIX-based system, it allows to play with it more and be creative instead of feeling being overwhelmed and somehow foruced by the tools. This also why some concept or methodologues can be fun to follow when they consist of several interdependent components where we can still see effect of each of them independently.
I prefer toolbox-based tools and concept then the "framework"-based one although it still useful in the cases where they are specifically made to solve.
Saturday, January 05, 2008
With all the tools available in the form of software, I still always have pencil and paper at my desk. Nothing can beat this tool yet and I don't think nothing will. The existence of softwares would only specialize it's positioning but I don't think it will threaten it's existence.
Here's the task that pencil and paper that I find still unbeatable :
- In coding, you deal with screen, taking occasional notes in physical form instead of fully in screen help to "refresh" perspective occasionally.
- Instant noodling, take scrap notes. I use freemind heavily for tracking what I am currenlty doing but when things got really hot, the speed of entering things to it cannot keep up with my head. The physical note-taking can keep up with flow of the mind really well.
- Braindump. Even in the not-too-hot situation, pencil and paper still shine in the brainstorming-style writing. For large-scope brainstorming, I sometime do mixing : Mindmap applications or outliner as a main media with papers for more chaotic, instant thoughts.
- Drawing your thoughts. Just try to draw your thoughts in Visio, good luck with that.
It's funny. People who do papers all day need software to help them. On the other hand, I think those who work on software should utilize paper more to help them finish it better/faster.
Friday, January 04, 2008
New year, new resolution, changes.
No matter how much I want and inspired to change in certain time e.g: after reading inspiring books, either in specific field like improving coding technique or life in general I can't seem to do it like I want it i.e: one big and lots of changes ASAP.
It seems that when I find out something new and interesting my mind goes "this is so true and now that I know this, there's no way I could do the other way, the change will be natural, tomorrow I'll be a different person for certain". We all know where that story will go.
So far, I conclude that people can only change one tiny little bit at a time and no more. It is true we can have insightful moments or dramatic shock but the most it can do is to change our perspective and how we see things. After them, the next step is to embrace the current reality first and not to jump in picking and throwing some part of our life to be build something brand new on top of it.
I think little thing is big, and big things is little in this case. I look at tiny step, done with care and a lot of of awareness, as a tip of the iceberg where a lot of complex things going on underneath it. In personal level,a tiny change could include changing a lot of assumptions, mental block, facing discomfort. In organizational level, a tiny change is the tip of the iceberg of change in workflow, resource management, office layout. Big change in this case could mean thin effect since the unrealistic feel of it would make the rest of your self/system/organization could only interested only in skim it, get pass the checklist, get through it ASAP.
So, what do we do with all the interesting coming our way so we can follow it up in tiny steps? I think it is best to queue ideas to followup on dedicated list and only pick several item from it to followup at one evaluable time. In short : separate collection from followup. For programmer, it's easy to relate this with issue tracker/bug tracker application. Without them, it's hard to have real and satisfying progress since you will operate always in urgency mode and trashing would most likely occur.
We end up with two things here : do things only a handful we could handle with a lot of care and use queue to put things coming your way. The third would be : fight the temptation to deal with things as it comes, you are in no condition to make the best judgement for it's followup (it's kinda like when you deal with classic sales trick that put you in urgent condition with something like short-term discount or "the price will increase next month" ).