Is Java becoming the new Cobol?

Apparently Java is becoming the new Cobol. It comes as no surprise that .Net has emerged as the contender to to Java's throne - especially given the Miucrosoft muscle supporting and driving it. It is also pleasing to see that Ruby and Rails is emerging as a contender also. It is also pleasing to see that Microsoft are supporting the development of Ruby with its IronRuby effort to allow Ruby to run on a .Net platform.

However, Java like Cobol has built a lot of infrastructure in enterprise environments and I'm sure that this will give Java some stickiness for considerable time yet.

Reading that article makes me wonder if it will become harder and harder for new languages and computing paradigms to emerge as time goes on? Does each new language or platform need to build a weight of infrastructural components in order for it to be a successful contender for the throne? I hope not and hopefully Ruby is the latest example of a language that works and is popularised simply because developers love it!

5 Generic Debugging Tips

These are some practical tips to help maximise your chances of success when debugging software problems - especially those hard to isolate problems. Most of these tips will seem like common sense but I am constantly amazed at how often they are overlooked! I've deliberately tried to keep these at a generic level and not tie them to a specific language so that they may be of relevance to most people.

1. Think: If you can quickly build and test your application there is often the temptation to keep trying things until the bug goes away. It is easy to get caught up in a cycle of "make a change - build - test (fail) - make another change ..." without really stopping to catch your breath. The danger with this approach is that when the bug goes away it is sometimes difficult to tell if the bug is fixed or if you have just solved a symptom. Although frustrating, it is sometimes a learning experience to have to debug an application or system that takes a long time to rebuild and test. This forces you to take a step back and to think carefully about what you can glean from your current data and what the next step should be. This will help you to better understand the nature of the problem and in doing so it will help to find the root cause more quickly.
2. Baby Steps: This is a really obvious but often overlooked practice. When debugging always take baby steps and only change one thing between tests. It is often very tempting to make a couple of changes or to skip a step, but this invariably results in an inconclusive test result and you will end up backtracking to figure out which change caused a change in behavior.
3. Simplify: Try and reproduce a suspect piece of code in a stand-alone environment. For example if a particular algorithm is miss-behaving, try and replicate this behavior in a simple application that only contains the algorithm and may be easier to control and debug. Similarly, if debugging issues in a kernel, it is often possible to replicate the code at a user level which is a much more friendly debug environment.
4. Tools: Become intimately familiar with your tool chain. Take time to learn the power and quirks of your unit test environment, debugger, memory leak checker, compiler, etc. If you develop on multiple platforms and use different tool chains on those platforms then learn them all!
5. Challenge Assumptions: Assumptions can be dangerous. How many times have you assumed that a particular piece of code is working only to find you many hours later that it contained the bug that was the root cause of the issue you were debugging or that it behaved subtly different than what you expected? In general it is good practice to assume nothing and to challenge all assumptions that you find yourself making.

Splitting large Scrum teams

Once upon a time we decided to use SCRUM as part of our development process. Since its introduction in our team, we have had a number of successful projects and we all think its the best thing since sliced bread. We love the fact that the entire team meet for a few minutes each day and think that it provides an effective means of communication between the team members.

Over time our team size has increased from about 4-5 to a whopping 15. We still practice SCRUM but I don't get as much out of it as I did when we had a smaller team size. Apart from the fact that it's difficult to get a space for our stand up meetings that can accomodate the entire team and still be able to hear everybody, I find it hard to keep tuned in to what everybody is saying. There is some pressure to stick to a single SCRUM for the entire team and not split into sub-teams. The rationale is to keep the daily stand up meeting as a communication channel between the entire team. So there are two problems:

1. How to improve the communication within the single large team to make it more effective
2. How to keep good communication across sub-teams and multiple SCRUM groups

Here is what I found from researching the problem:

How to improve the communication within a large SCRUM team?

• Hyperproductivity In Large Projects Though Distributed Scrum - relates to SCRUMs between distributed team members but the team size was 59!!!!
• Hmmm, there seems to be a lack of advice here! The only advice that I could find was to split the team into smaller sub-teams - the "scrum of scrums"!

How to keep good communication across sub-teams and multiple SCRUM groups?

• Historical data that suggests keeping the SCRUM team size under under 7
• The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information
• Inefficiencies and large teams - "Two common pitfalls for crowded teams: miscommunication and lack of motivation"
• How to organize work and structure a project with multiple teams: Let small teams focus on solutions to specific problems and coordinate activity between teams.
• Scrum of Scrums

I guess the tactical approach to convincing the team to move towards smaller sub-teams and multiple SCRUMs is to point out that the larger team size is reducing the effectiveness of communication within the team. However, this must quickly be followed up with evidence that co-ordination and interaction between the smaller teams can address the communication gap caused by the split. To this end, I think I like the idea of the scrum of scrums approach where there are multiple scrum teams, and one member of each team attends a SCRUM with one member from each of the other teams. In effect this one team member becomes the communication channel between the teams.

Always an apprentice?

With the rate at which new software languages and technologies are appearing, its a tough job for a software engineer to keep up with the latest developments and trends as well as keeping existing skills sharp. Just as you feel you master one language or technology, a new one comes along and your apprenticeship starts over in this new field.

One of the best ways that I have found to both learn new languages/skills and to keep existing skills sharp is to practice each skill as much as possible. For programming languages this means regularly writing pieces of code in each language in the toolbox. I try to use each language that I know at least once a month for languages that I have become proficient in and at least once a week for languages that I am learning.

Dave Thomas describes this concept in greater detail in his CodeKata series.

I find the use of programming puzzles and challenges as excellent ways to find concise coding exercises that don't soak up to much time but yet provide opportunities to hone & develop skills as well as often providing opportunities to learn about new libraries, packages, algorithms etc.

Some of the best coding problem / challenge sites that I use are:
http://codekata.pragprog.com/
http://www.pythonchallenge.com/
http://www.topcoder.com/

Simple container dump using STL iterator

Quick and dirty printing of containers contents in C++ using STL ostream_iterator ...

#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

int main()
{
    vector<int> v(10);
    generate(v.begin(), v.end(), rand);

    copy(v.begin(), v.end(), 
        ostream_iterator<int>(cout, "\n"));
    return 0;
}

Pillars of Concurrency

Excellent article on decomposing and categorizing concurrency traits by Herb Sutter ... http://www.ddj.com/dept/cpp/200001985

The three "pillars" identified in the article:

1. Responsiveness and Isolation Via Asynchronous Agents
2. Throughput and Scalability Via Concurrent Collections
3. Consistency Via Safely Shared Resources

An interesting reference from this article is to an earlier article from Herb illustrating why lock based programming is hard and insufficient: http://www.ddj.com/dept/cpp/184401930