KludgeHack

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.

Making Laziness Work for You
16 June 2007 in Personal Experience | Comments (0)

Leo Babauta at FreeLanceSwitch wrote another creative GTD article about 10 Ways to Make Laziness Work for You.

You’re feeling lazy right now, and reading blogs instead of doing what you’re supposed to be doing. That’s OK — we all do that. We’re all lazy, in different forms, at one time or another.

But let’s look at how to make that laziness work for us, and how to turn lazy into productive.

Being a huge fan of laziness, to some extent, I appreciate methods to improve productivity. Turning a negative side of human beings, in a positive one.

I’m specially addicted to “Wait until the last minute” and “Go with what excites you.”.

How to write awesome code
31 May 2007 in Personal Experience & Programming | Comments (0)

I’ve been wanting to write a HowTo, but couldn’t find an appropriate subject. Finally occurred to me to talk about something I really appreciate: techniques to write good, simple and comprehensible code.

Writing good code always was a challenge to me, mainly because the definition of good code isn’t somehow very clear.

So, what is Good code? I believe that is a program that works flawlessly and has no bugs. Unfortunately, this can’t be easily archived, at least in practice.

Design, I think is the key to writing the good code. Planning in advance what the code must archive is crucial.

Whatever is the language of choice, all good programming must show this same good qualities:

• Simplicity means you don’t do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity—of organization, implementation, design—makes your code more reliable and bug free. There’s less to go wrong.
• Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing “taxrate” instead of “tr”.
• Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.
• Efficiency means your program is fast and economical. It doesn’t hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.
• Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion—which is almost always elegant:
• int factorial(int n) {
      return n==0 ? 1 : n * factorial(n-1);
  }
• Clarity is the boss of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines. The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.

All of these mean nothing if you don’t really understand what you’re doing. Good programs are more about a clear goal than coding skills. That’s why planning in advance is important. If you can’t write it down, if you can’t explain it to others, you don’t really know what you are doing.

A good programmer, is the one who applies such quality’s on their code 100% of the time. They understand the benefits of such code. But such skill, needs practice to grow. Writing great code doesn’t come fast and easy.

One other very important point in writing really good code, is using automated tools to test, profile and verify your code. There are actually many tools for almost every *popular* language to simplify the task of the programmer in simplifying, optimizing and speedup the code.

For .NET programmers I recommend using this tools:

• FxCop (code analysis tool) to check the code conformance to MS .NET Framework Design Guidelines.
• NUnit (unit-testing framework) for creating tests on your code.
• Lutz Roeder’s .NET Reflector is a class browser and decompiler that can examine an assembly and show you just about all of its secrets.
• NDoc (code documentation tool) will automatically generate documentation for your code using reflection to examine the assembly and using the XML generated from your C# XML comments.

There are others great tools, and not only for .NET. As always, a quick search away.

Finalizing, there’s so much I’ve left out, but I want to reinforce the idea of Simplicity. Writing code to make you look clever isn’t a good idea. Even if you are all that clever, don’t try to create obfuscated code, making to many in only on row of code. This seems something good, but it completely costs you when you face the inability to quickly fix a bug in it. The point here, is that we shouldn’t make code even less comprehensible. The programmer should apply some skills of code refactoring. There are others ways of ending on Worse than Failure.

I would also recommend you to read Paul Stovell post “We are what we repeatedly code”.

Happy coding!

External Posting…
23 March 2007 in Blogging & Personal Experience | Comments (0)

Although I use Wordpress as my blogging system, it’s not practical to use the Web interface every time I want to write a post, even when I just want to change or even manage some posts/comments.

There are those who use Browsers plugins like Firefox ScribeFire (previously Performancing), those who use Browsers already fully equipped for this, like Flock and some use Windows applications like the famous Windows Live Writer but recently I found out that my new Word 2007 also brings blogging features. What’s better than use a well-know Word processor to publish content?

If you have Office 2007 installed, give it a try…