admin

…So I’m having this nightmare about a marauding robotic giant Squid controlled over the internet by masterminds unknown…Bruce Schneier continues his squid themed Friday blog posts!

Microsoft have recently released Performance Console (PerfConsole) 1.0 a tool that can be used to simplify and analyse Visual Studio profiler output:

“PerfConsole is a simple performance investigation tool which tries to adopt a
debugger like experience to drilling into Visual Studio Performance Profiler
generated data.”

This is for those managers who believe they can promote team work by giving raises to just a few members of a team! If you are a manager that has recently experienced high staff turnover, I suggest you read this carefully:

1. When team members are in competition with one another for their livelihood, team work quickly evaporates.
2. There is no greater demotivator than a reward system that is perceived to be unfair. It does not matter whether the system is fair or not, only that there is a perception of unfairness.
3. When management exhort team members to do what is clearly impossible through the offer of rewards rather than helping to make the task possible, people are likely to be insulted and give up without even trying.
4. Optimising a part of chain invariably suboptimises overall performance. One example is separating software development from support and maintenance. If developers are rewarded for meeting a schedule even if they consequently deliver error-prone code without automated test suites, then support and maintenance will cost far more than was saved during development.
5. Once team members get used to receiving financial rewards for meeting goals, they begin to work solely for the rewards, not the intrinsic motivation that derives from doing a good job and making their company successful.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

I’ve been hearing a lot of good things about this book Beyond Bullet Points by Cliff Atkinson. I haven’t actually got my hands on a copy yet (one topic sure to get me on a rant, is how it is quicker to get a shipment of books from Amazon in the US to my doorstep, faster and cheaper than going to a technical bookseller in Perth), but I will presently.

I noticed that a recent talk by Brad Wilson on the topic of agile pair programming was written using these techniques, and several other high profile presenters seem to be taking Cliff’s advice on board. Definitely one to add to the reading list.

Want to hear something really scary? On average, a programmer reads just one technical book a year (Code Complete: Steve McConnell). It got me thinking; let’s be optimistic and say that the average every programmer reads 2 technical books related to their work each year. Now assuming you have a productive working career from the age of 20 to 60. That means you will read just 80 technical books in your entire working life! As a consequence, it means you should be very discerning about which ones you read. You may not have realised it but you just don’t have time to read any poor or out of date technical books!

OK. Now you have decided to only read useful books, how will you pick which ones you should read? Jeff Atwood put up a list of recommended reading for developers, and I’ve previously posted a list of recommended computing books. One that is on Jeff’s list that I really should add to mine is The Pragmatic Programmer: From Journeyman to Master. You could probably read this book together with Code Complete and be well on the road to enlightenment!

Brad Abrams has posted these useful answers to common .NET Framework deployment questions.

Microsoft profits fell to a paltry $2.8 billion this quarter, due largely to huge legal expenses.

Microsoft executives have known for some time that sales in the Operating System market will inevitiably fall off and that Microsoft’s period of explosive growth is at an end. Once that happens, if you want to continue to grow then you need to take market share away from others. Which means leveraging your dominant position into other areas, such as business document management, document workflow and CRM, to name a few.

Just under 3 years ago, I was working alongside a team producing document management software for fairly large companies. I tried to warn the manager of this team that there was a strong likelihood that Microsoft would be moving into the area of document management and workflow (i.e. in addition to the existing SharePoint software) and that they should draw up a 3 – 5 year business risk/strategy plan in order to decide what could be done to mitigate this risk, and indeed how long a market would exist if Microsoft entered the arena. Instead, he choose to put on the blinkers and completely ignore this advice…

Whilst I don’t have a crystal ball, it seemed inevitable that the outcome would be that in 1 – 2 years, Microsoft will have a product (something like ‘WorkPlace 2007’ or OfficeFlow or OfficeAdvance, you get the idea!) that it will compete with existing content management systems like Documentum, DocsOpen, HummingBird or OpenText. EMC, the owners of Documentum, already seem to be moving away from this area.

If you haven’t heard or read Bruce Schneier on Security I suggest you head over to his blog. He’s a leading expert on all things security and a voice of reason in a mad world. It makes you wonder to what extent the ‘war on terror’ is simply a replacement for the ‘reds under the bed’ of the cold war.

I’ve spoken with several experienced developers in recent weeks, discussing whether the .NET framework’s two main languages, C# and VB.NET, are in danger of becoming too complex for the ‘average’ programmer, or indeed for the average programming task (whatever that might be). While you could argue that complexity is necessary to model complex problems and domains, the continuing abstraction of programming languages does not provide much support for this view. A complex, general purpose programming language will rarely be a good substitute for a domain specific language (generalisation versus specialisation).

Maybe I’m just getting old and my shrinking brain can’t handle all this complexity, but deep down I feel that code should read like prose. I do not want to waste valuable time trying to figure out what a chunk of code is trying to do, it should be apparent almost immediately. Is this unrealistic? Possibly, but the driving force behind the evolution of computer languages has always been to simplify and increasingly shield programmers from the low level implementation details so that they can concentrate on solving higher level business problems.

I have programmed in C/C++ for over 20 years. When I first encountered VB in 92-93, my first thought was that it was a ‘toy’ language designed for non-programmers to write quick and dirty GUI applications. I could not have been more wrong. I did not have the maturity at that time to realise what it represented and its possibilities. It has had a profound effect on the software industry not only in terms of what could be achieved quickly but it also raising the expectations of what could be achieved quickly! VB’s obvious attraction and strength was that it empowered less experienced programmers to achieve results that were previously only within the reach of ‘guru’ programmers. Of course, you still had to delve into the Win32 API to get at some of the more ‘advanced’ features (exemplified by Dan Appleman’s work in this area ).

What made VB so attractive was that it was simpler and much more productive than coding in C/C++. If VB.NET and C# both increase in complexity, is there a reason for having two languages that serve the same purpose? As C# and VB.NET evolve further, will a single generic .NET framework language emerge, or will a ‘new VB’ diverge from C#?
In this terse example on anonymous delegates from Developing for Developers “…, here’s two lines of code that produce a list of all files larger than a given size in a given directory”, it is not immediately obvious what is being performed inside the method even with the previous description (BTW that post at Developing for Developers provides a good introduction to anonymous delegates):

OK, this is a hand-picked, contrived example and not even the most efficient way to accomplish this. You could break this down into separate lines, but the point is the language is enabling, perhaps even encouraging us to write hard to understand (and therefore maintain) code. This reminds me a little of ‘dense’ C code! [In fact, this issue has recently been addressed in C# 3.0 using Lambda Expressions…]

You could argue that less experienced programmers will simply not use the new, more complex features of the language(s), but experience would suggest otherwise.

Please don’t misunderstand me: these powerful language features obviously have their uses. I’m just intrigued about the direction these two languages are taking. With power comes complexity, and with it also the possibility of subtle, hard to understand bugs.

Is there a need for a ‘new VB’?

I had to maintain some fairly straight forward pre-.NET C++ code today. It really made me appreciate the .Net Framework! I was experimenting with a few performance ideas and spent an hour researching why it wouldn’t compile (a conflict between STL library and MFC) which could only be fixed by moving an include into “stdafx.h” to precede all others, then another involved solving a linking problem caused by the common runtime library conflicting with the statically linked MFC library, which required an explicit library link order to be defined!

.NET really does rock!