KludgeHack

FixThat!
26 June 2007 in Blogging & Links | Comments (0)

My college friend Filipe, started a new website: FixThat!

Where you go when you want to Fix That!

From computer hardware to house holding, you can always find daily new tips… make sure you take a look…

Microsoft RoundTable - Videoconference on Steroids…
26 June 2007 in Microsoft & Tech | Comments (0)

Microsoft RoundTable (previous RingCam) is a “new”, and very cool, videoconference system powered by 5 built-in cameras featuring a 360º panoramic view.

Tom Keating from TMCnet made a recent review of the system. He made some tests with Microsoft Office Live Meeting 2007 online version (beta) and Skype.

I recommend you take a look, its a pretty complex system that provides interesting results. I certainly was impressed, specially with the active speaker video switching functionality.

Although not released for general availability, the Microsoft RoundTable is expected to retail for around $3,000 putting this in the category of high-end videoconferencing systems. However, with fuel costs and other travel expenses, a high-quality, high-end videoconferencing system can pay for itself very quickly.

Introducing Regionerate (pronounced ri-jeh-neh-rate)
25 June 2007 in Programming | Comments (2)

Regionerate is a free new open-source tool for developers and team leaders that allows you to automatically apply layout rules on C# code. You can view a screencast here.

Regionerate runs on Visual Studio 2005, Visual Studio Codename Orcas Beta 1, #develop 2.0, NAnt and on command line.

The tool can be very useful by default, but some more extending can also adapt its current process style by creating a new Code Layouts Schema with XML files. You can find a simple tutorial here.

Also, the newest version  (0.6.0.5), released today brings support for Name & Type filtering and #develop support.

You can download the tool directly from here.

Bridging the gap from C++ to C#”.
25 June 2007 in Microsoft & Programming | Comments (0)

Channel 9 has a small (22mins) Ron Jacobs interview with Manu from Microsoft Israel on “Bridging the gap from C++ to C#”.

Manu speaks about ways to bring the two languages together, creating interoperable code.

You can see the clip here. You can also download the MP3 or WMA file.

Avoid chaos, don’t let bugs take your project away
24 June 2007 in Personal Experience & Programming | Comments (1)

Generally I really enjoy reading all kinds of books and articles about real life programming, specially when is about the difficulty to create an effective development process. Dreaming in Code, is such book, focused on the problems that make the development process so difficult.

Bug fixing, is probably one of the biggest challenge in every development process.

Often, when doing the boring and painful task of fixing flaws and patching bugged code, I find myself looking  for ways to do this in a more controlled and productive manner. Because, the more effective way you control your time, the more productive you will likely be.

There is no doubt that most programmers are optimistic and assume that each bug can be fixed quickly, in a short estimated slice of time.

Great books like Dreaming in Code shows that, from a practical point-of-view, this estimates are only a myth. If there is something unmeasurable in computing, that would be definitely the time it takes to fix a bug.

Bugs can even take more time to fix, than it took to create the entire software. On the quest to fix a unique bug, a programmer in the worst case scenario, can find himself in a infinite loop, finding more bugs on the quest to fix one. Some bugs that could at a first look appear trivial, can always surprise you. There’s always the need to plan for uncertainty.

With such failed evaluation system, how can programmers create a fast and controlled triage system? How can the development team prioritize bugs? Is there a pre-emptive choice when comes to bug fixing?

If the time a team spends on fixing flaws can be such a big real cost to the Company, how came there isn’t yet a better system?

Although Scott Rosenberg done a terrific job with his book book Dreaming in Code, he doesn’t provide a solution to this problem.

But he compiled a list of software development mistakes to avoid, that I think should be shared:

1. Don’t leap ahead before you look backward.
The software industry isn’t introspective, says Rosenberg. “There isn’t a lot of examination of past mistakes. That’s the classic technique of engineering in the physical world—the examination of past failures.” Before launching a new project, review past errors and determine how to avoid them.

2. Don’t forget to plan for uncertainty.
The biggest mistake software developers make, says Parkinson, is to assume their time estimates are perfect. “People can be distracted by many kinds of unplanned events,” he says. To compensate, Parkinson advises introducing “slack”—contingency time to be consumed when adjustments are needed.

3. Don’t cave to unrealistic expectations.
Too often, software developers overpromise what can realistically be delivered in the allotted timeframe. “Managers tend to get into saying, damn it, I want it yesterday,” says Rosenberg. It’s a dangerous game that leads to faulty code.

4. Don’t expect uniform productivity.
It’s unrealistic to expect the same amount of output every day, says Parkinson. “I have seldom seen this happen,” he says. “Better to manage trends, where you can smooth the daily data into a useful indicator of progress, than to panic over daily fluctuations.”

5. Don’t go for the grand slam.
Holding off a launch before the entire project is finished might be a mistake. “If we try to design a system that does everything everyone wants it to, we’ll never have any system,” says Rosenberg. Instead, break projects into small bites. “Any opportunity to do that is to be seized,” he says.

Concluding, I advise that if you appreciate a experienced developer point of view on real life developer challenges, read Scott’s book. He shares his thoughts and experience on this matters, trying to figure why “Software is so hard”. I guess every programmer should know the crazy business they are into.

Quoting Donald Knuth, author of The Art of Computer Programming:

Software is hard.