Professional Software Development

What defines a professional developer? The initiative „Clean Code Developer“ (german only, english version using Google Translate) tries to facilitate a common understanding of this question. It has started to collect principles, rules and best practices for better software.

They see as basic principle for becoming a professional developer to be self-conscious about your work and always try to improve yourself as well as to adhere to some common best practices and working principles. Trying to lead developers to more professionalism, they have also collected a lot of concrete recommendations for the day to day work. To make it easier to follow these practices and rules, all recommendations are grouped by a so-called grade system. So you can start with the easy ones and get to the maybe not so easy to follow rules later.

Even if you don’t agree to all suggested practices and principles, the side is definitely worth a read since you will find a lot of good practices concentrated on one location. Additionally, they also maintain a link list for useful tools and frameworks.

You can find the Clean Code Developer initiative here.

The most important thing about optimization is analysis

You can’t fix a problem by simply trying different solutions to see if they work. In order to fix a problem, you have to understand the problem first.

So, please, if you’re a developer, don’t assume saving a couple of CPU cycles here or there will solve the problem. And if you’re a manager, don’t assume some new hardware will solve the problem. Do some analysis first. Finding out if disk I/O, memory, CPU cycles or single threading is the problem is really not that hard if you spend a little time thinking about it and benchmarking various things. And in the end, you’ll have a much better overview of the situation and the problem, and you’ll be able to come up with specific solutions which will actually work.

And that’s how you save money.

via | Log.

WPF Startup Performance

If you are developing a WPF application, you know about the increased startup time compared to native applications. One of the reasons is the time needed for loading the CLR the first time it is used after a reboot, but there are a lot more aspects affecting the time until your application window is shown on the screen and fully functional. Although .NET 3.5 SP1 improved the initialization time noticably, it is worth to understand the pitfalls and to design your application for fast startup and initialization. The following links will provide you some insights information: WPF Startup Performance weiterlesen

Packaging .NET assemblies

Recently, I stumpled upon Ralf Westphal’s post about packing of .NET assemblies for releasing (sorry, german only). The tool he describes is called Netz and really seems to be useful for having the possibility to break down separate functionality into specific assemblies at development time but not having to deliver a lot of separate assemblies for release.

I did not yet have the time to try Netz by myself. But it is good to know that such a tool exists and will try it out at the next opportunity.

Turn off your step-thru debugger

A good point and definitely contains some trues:

„If you get in the habit of using a debugger,“ my mentor pointed out, „you’ll get lazy. A certain part of your brain shuts off, because you expect the debugger to help you find the bug. But in reality, you wrote the bug, and you should be able to find it.“

Still stunned, I asked: „What do you do when you have a really nasty bug?“

He said something I’ll never forget. „I make the machine tell me where it is.“

Make the machine tell you where the bug is. What a wonderful piece of advice. It’s the essence of troubleshooting, whether you’re trying to fix a car that won’t start, trace an electrical fault, or debug a piece of software.

via assertTrue( ): Turn off your step-thru debugger.

Developing for the Windows 7 Desktop

If you are currently investigating on how to integrate your applications into the Windows 7 desktop, the following links may be a good starting point:

Make sure that you are also familiar with the Application User Model IDs:

Application User Model IDs (AppIDs) are used extensively by the taskbar in Windows 7 and later systems to associate processes, files, and windows with a particular application. In some cases, it is sufficient to rely on the internal AppID assigned to a process by the system. However, an application that owns multiple processes or an application that is running in a host process might need to explicitly identify itself so that it can group its otherwise disparate windows under a single taskbar button and control the contents of that application’s Jump List.