42

I am trying these out now. We will see how it goes. 

Link to 10 First Tweaks to Windows Vista After Installation - Vista Horizons

A great help and starting point when configuring a new WPF environment.

Link to Tim Sneath : Building a Perfect WPF Developer Workstation

I read a blog recently on the definition of project success and was surprised by the definition. The definition, based on Pier’s experience with agile development, is when the customer is happy and when the project team is happy and satisfied. I will probably be vilified for this, but I disagree. A project can be very successful and the project team miserable. I don’t recommend it, but it is true. The project is paid for by someone. That person(s) defines the success criteria. Whether they use that criteria or not is a different issue, but let us assume they do. If you meet those criteria, success; if not, failure. Further, depending on those criteria, it is possible for degrees of success or failure.

It may seem incorrect to discount the project teams opinion and I personally do strive to keep my teams happy whenever possible, I have had the experience many times to be on projects I hated. We all get them. The military is practically comprised of doing projects people do not want or like to do: ditch digging, latrine duty, kitchen duty, patrols, and so on. The corporate world has the same. Some of the most common ones that I have seen are report generation, end of month / quarter / year tasks, the entire Year2K problem, and the management quid-pro-quo deal (in which a manager agrees to lend a team to do something for another manager). As a manager, I have assigned projects to teams knowing they would be unhappy, but the work needed to be done.

I will even go further. I have seen vastly successful projects in which the client was not happy or satisfied. This happens frequently in world of finance IT. Many clients frequently expect miraculous turn around times, clairvoyant development teams, and the ability to absorb feature creep without any impact to delivery schedules. Many of the tasks are not even what the client really wants, but what they need to support settlement or legal & compliance. The project team & the client see it as a necessary evil and delaying their whizzbang new feature.

So whats my point. Not all projects are the result of client wants, but the result of client needs. These projects also need to be successful, but very few will make the project team happy or the client happy.

Yesterday Bill Gates announced his intention to leave all of his day to day activities at Microsoft within two years. The media heralded the news as the end of an era. The changing of the guard metaphor was used in numerous articles. The stock market reacted by pushing Microsoft stock up a grand total of $0.03. That’s three cents as in pennies. This left the media with no story. There was no reaction. The world yawned.

The prevailing wisdom for years was that Microsoft and Bill Gates were co-joined. They were assumed to be one and the same. This misconception is a dis-service to many highly intelligent individuals that work at Microsoft. While Bill did set the vision and the direction, his impact has been waning for years. As the company grew and talent was nurtured or purchased, the company became more than Bill. The company is now a repository for some of the smartest people in business and technology. The company is well positioned to face the next era in computers.

The clean transfer of power from a companies founder to the leaders for the next generation is a rare event. It is a testament to the planning, foresight, and maturity of the old generation of leaders that it can be achieved. The true hallmark of this event is that it is happening so smoothly that the investors consider it be factored it in to the price already.

Well done Bill. Good luck to you and Melinda in your charitable work.

Recently, one of the developers that work for me got highly animated while pointing out an issue with the C++ code of another developer on the team. Without all the emotional buildup, it can be summarized as a class is allocated using new with a reference to a containing class passed into the constructor. The constructor adds itself (this) to the collection class and exits. The containers destructor contains all the logic to actually delete the elements it contains. This code works. There are no memory leaks. Some readers may already know. It was all about scope.

While he was pointing this out, I was remembering an age old rule that I always follow. I have been following it so long that I never even thing of why I follow it. The rule is simple: All creation and deletion must happen in the same scope. Now before the purists go nuts on me, there are exceptions or more likely interpretations - as there are to most rules. I consider smart pointers to actually contain the pointer, usually by putting the allocation in the constructor of the smart pointer. This makes smart pointers a follower of this rule through liberal interpretation. There are also times when it is necessary to do some pointer ownership transfers. These are exceptions and require a significant amount of comments in the code to be maintainable. The last of the big three (there are others, but these three are the big ones I have run across) is COM. COM allocates in the factory, and deletes in the release. Two different scopes and thus an exception. So moving past these points, I have always strived to ensure that all allocations and deallocations happen in the same scope. This scope being liberally interpreted as meaning not just the method scope, but potentially two methods in the same class. This allows for the common database class methods of AddRow() which returns a new row and DeleteRow() which takes the row and actually deletes.

Ok. So now that I stated one my rules, I returned to the conversation with my developer. He was livid over how unmaintainable the code is as written. I told him of my rule, of which he has heard of before, and he realized that this is exactly the type of code I was trying to avoid with this rule. After working with me for nearly four years, he finally knew why this rule existed. Prior to this, the rule was just something I said. Now he is a convert to the rule. Even the addition of a couple of methods for add and delete would have made the code easier to read and maintain despite more lines of code.

His epiphany was amusing to see. It reminded me of my own some years back while coding in C using the Turbo C compiler. I find the same rule still applies to nearly all other resources and in the age of managed code. While I am not allocation and deleting memory, I am acquiring and releasing resources. Overall this rule is one my all time favorites and has saved me significant grief from maintaining crappy code.

I just thought I would share it. Comments? Opinions?