Gunnar Kudrjavets

Paranoia is a virtue

  • Ternary search trees

    About a year ago I was in pretty embarrassing situation because I had no clue what ternary search trees are and I had to write some code to implement efficient way of searching and storing strings. Jon Bentley’s and Robert Sedgewick’s article "Ternary Search Trees" was published in DDJ and is a very good paper to start with. Unfortunately to access the article you need to be DDJ subscriber but if the source code is enough for you then the demonstration program by authors is located here. Ternary search trees are extremely helpful in solving an entire class of searching related problems which may come up in real life.

  • "The Apprentice" for software developers

    Lately it seems that to be part of any social discussion you need to be watching "The Apprentice". I’ve been noticing the similar phenomena during last couple of years when it comes to "The Sopranos" and it made me feel like a total outcast because I haven’t seen a single episode of "The Sopranos" and I don’t intend to ;-) However, to blend in I’ve been following "The Apprentice 2" and my colorful imagination tells me that what will be really cool ;-) is the similar show about software developers. You can already imagine the following dialogs in the boardroom:

  • Having majority of the tests implemented before feature is added to the code base

    One of the things we’re currently trying to do is to align development and test processes and schedules more closely. The fuzzy description of initial problem statement is the following: “Whenever the implementation of some feature is added to the code base then at the same time majority of tests for this feature must be also implemented and some specific criteria about the quality of the feature must be met.”

  • Diaries of a former caffeine addict ;-)

    More than three months ago I decided to stop drinking coffee and switch to the green tea. I stopped drinking soda already years ago and currently my average intake is a can of Coke once in two-three months. Welcome to almost caffeine-free lifestyle ;-)

  • Popular agile software development sites

    Today evening I had finally time to read through the September issue of ACM SIGSOFT Software Engineering Notes. In addition to the usual goodies they have a nice overview ("Surfing the Net for Software Engineering Notes" by Mark Doernhoefer, page 20) of most influential/known/popular sites about different agile software development methodologies. As I'm tired of trying to keep my bookmarks synchronized across the number of different computers I use, I'll publish this list and some additional sites here:

  • Best practice - daily investigation of the test case failures

    When it comes to the best development practices then daily build and Microsoft are practically synonyms. Not a big surprise. Jim McCarthy says it’s the heartbeat of the project. Steve McConnell covers it thoroughly in his books. Even Edward Yourdon thinks it’s worth mentioning. Etc. etc. To summarize: daily build is A Good Thing.

  • Is anyone (still) using CASE tools?

    Last weekend I was reading "No Silver Bullet" again and as a direct result of this I accumulated number of pessimistic thoughts and therefore I'll rant about one specific thing for a while. In my mind I classify different software engineering methodologies, tools, and approaches into number of categories. One of them is called "esoteric stuff." For example, formal methods in software engineering belong IMHO under this category. Lately I’ve been thinking about moving CASE (Computer-Aided Software Engineering or use your favorite meaning for this acronym) tools under this class also. Why? I believe that generally the world of software development is mostly self-regulating. If something is good and causes better productivity then people use it and over the course of time more companies/people start incorporating "this something" into their processes. If something is good on paper, but doesn’t work IRL then eventually less and less people will use the technology and finally it’ll disappear from the radar screen. For myself I’ve found a couple of reasons to distance myself from CASE tools:

  • Professional Development Handbook/Ladder and SWEBOK

    Probably most of the people who have ever read "Code Complete" or its second edition or any other book by Steve McConnell have browsed systematically through Construx’s web site. One of the most interesting pieces of information for me is their "Professional Development Handbook" and "Professional Development Ladder". Sure, Microsoft has its internal equivalent documents, but nevertheless it’s very educational for more complete world-view to understand what’s happening in other software companies or towards what industry is moving in general. I usually try to reread these documents every three months or so to understand how my personal thinking has changed ;-)

  • Development:test ratio causing software quality to self-stabilize

    Today I attended one excellent talk covering software engineering culture in general, things which currently need improvement, some internal case studies etc. Test to development ratio was also pointed out in this talk and one interesting thought was mentioned during this presentation. Microsoft is different from most of the software companies by development and test organizations having very similar sizes. Hypothetical little feature team may consist of 6 SDE-s, 4 SDE/T-s and 1 STE for example. What would happen if ratio of testers and developers will be 1:10 for example and at the same time you would have a top notch development team who’ll be obsessive about code reviews, unit testing, proper engineering practices etc? Natural reaction is that the product quality will be doomed ;-) However, one of the projected outcomes was that the product quality will be self-correcting and will stabilize itself automatically to the level that would be acceptable for shipping? You know, all these factors like people developing the software understanding that they’re the ones responsible for product quality and there’s nobody else ;-) Major assumption is of course that peer pressure and strong personal accountability for the quality will be applied.