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 Electricmonk.nl | 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.

Writing better commit messages

If you and your team are in the habit of writing good commit messages, it can save everyone a tremendous amount of time and effort. Other developers can very quickly see what you’ve done. It’ll also save tons of time tracking down commits from the past when you need to find them. A good commit message serves exactly two purposes: it gives other developers an explanation of the commit, and it gives some documentation for future searching.

Read one for some good rules on writing commit messages.

via lbrandy.com » Blog Archive » Writing better commit messages.

Use Threads Correctly = Isolation + Asynchronous Messages

Here are the key things to know about threads:

* Threads are for expressing asynchronous work. The point of being asynchronous is to let the units of independent work in the application all run at their own speeds and better tolerate each other’s latency.

* Threads are a low-level tool. Threads are just „sequential processes that share memory,“ and that kind of freewheeling anything-goes model doesn’t provide any abstraction or guard rails to make good practices easy and bad practices hard. As aptly criticized by Edward Lee in his paper „The Problem with Threads“ [2], threads let you do anything, and do it nondeterministically by default.

* „Up-level“ them by replacing shared data with asynchronous messages. As much as possible, prefer to keep each thread’s data isolated (unshared), and let threads instead communicate via asynchronous messages that pass copies of data. This best practice inherently encourages writing threads that are event-driven message processing loops, which gives inherent structure and synchronization and also improves determinism:

via Dr. Dobb’s | Use Threads Correctly = Isolation + Asynchronous Messages | März 16, 2009.

Don’t Live with Broken Windows

As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can’t fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn’t trust it, shouldn’t go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. „Well, that’s broken. Oh I just broke that. Oh well.“

via Don’t Live with Broken Windows.

Orthogonality and the DRY Principle

A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you’re constantly dancing on all the controls to keep the helicopter stable.

That’s kind of similar to code. We’ve all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you’ll always get that kind of distributed bug fixing.

via Orthogonality and the DRY Principle.