Did it ever occurred to you that one particular idea or technology which is pretty concrete and utilitarian can suddenly reveal unexpected and beautiful applications? Sometimes one even would not think that any technology should be applied at all. This is what really amazes me about computing and will never our profession completely mechanistic. Through ACM TechNews I've read article Virtual Extras. It subtitle did not promise anything "extra" at all. Just serious advances in development of animated mob scenes:

Giving each member of a digital crowd its own personality could make animated mob scenes more realistic.

But when you read further you come across

... software even manages to capture the way in which two crowds of people, moving through a narrow corridor, naturally form two opposing lanes.

With this things start getting interesting. And finally you get

Beyond movies and games, there's increasing interest in using crowd simulation to help conduct fire and disaster assessments of large public spaces...

Isn't it amazing that purely entertaining-targeted research suddenly finds such non-trivial application. Do you feel the same after reading the article?

Long ago I took a huge interest in functional programming languages and their theory underpinnings. My master's thesis also was related to functional programming. But later I went into full-time position in industry and cruel nature of business started putting its real-world limitations on technology selection for software projects... In recent issue of local IT magazine a second in a series article on functional programming was published and I really enjoyed going back to the times when I lived in this world. So if you happen to know Russian and know something about functional programming or, probably, think you know everything about programming, but never heard the words Haskell, higher-order function or strong typing, I encourage you check out these articles:

• λ-calculus
• Up - to monads, down - to registers

Today I was thinking of establishing a clear versioning system for one of the projects I'm managing. Usually I start such kind of activities with research of past experience on the Internet. I did so this time and found a bunch of interesting links. Here are some to name a few:

• Software Versioning article at Wikipedia provides good overview version numbering schemes adopted for different products. Also interesting is discussion of political implications of software version numbers.
• Eclipse Version Numbering discusses the topic as applied to Eclipse platform. It nevertheless gives a good reasoning behind one particular scheme and show what software engineer needs to think about with regard to versions and configuration management approach.
• Which Version of Version? Also describes one particular versioning scheme.
• What's In a Version Number, Anyway? Raises usability concerns of version numbers for mere mortal software users. Microsoft Office versioning approach is also discussed here. Additional point of interest is comments to this post.
• Decoding Office Build Numbers. Description version numbering scheme currently used by Microsoft Office products.

I generally agree with Jeff's ideas that versioning often is overly complicated and confusing for end-users and even sometimes for developers themselves. I think developers' love for "magic" numbers and words comes from natural human's desire to differentiate from other humans. In this case developers differentiate by possessing knowledge about all those tricky version numbering approaches which are hardly comprehensible by mere mortals.

Albert Einstain once said "Things should be made as simple as possible -- but no simpler." I believe we should follow his advice in giving versions to our products.

Yesterday driving the city I noticed a big board which invited to buy a flat in a house. The interesting fact about this sell was that the is not built yet and the construction has not even started! But they have a fully visualized 3D-model of the house which you can use to imagine how your new dwelling will look like. I doubt that anyone has any apprehensions that real estate company can and will build the house so that it will look exactly like it looks in the model (i.e. in the project). So what they are essentially doing they are selling a design, not a completely usable product. Can you imagine anyone selling a design of a software product to end-users? Or even better, can you imagine anyone buying that?

Unfortunately, in software industry we do not get that level of credibility like they do in civil engineering industry. But I do believe it is possible with of software engineering profession. If you agree with me the Professional Software Development by Steve McConnell will reassure you. If you do not agree this book will, probably, persuade you that it is possible.

When I was reading A Conversation with Jeff Bonwick and Bill Moore in the latest issue of the ACM Queue there was a passage that really touched my heart of software engineer:

PAWEL JAKUB DAWIDEK At first I just wanted to see how much work it would take to port ZFS to FreeBSD. I started by making it compile on FreeBSD, and once I did that, I was quite sure it would take at least six months to have the first prototype working. The funny thing was that after another week or so, ZFS was running on my test machine. It was truly surprising that the code was so portable; it was self-contained and I had initial read-write support after 10 days of work.

Isn't it really the essence of internal quality of a software system?

You may disagree but to me software product|design|implementation|etc. is great when you get something that you originally did not plan to get. This happens when you do not compromise a single bit of quality of what you do even it is not stated in the requirements. Quality always pays-off, but you have to invest in developing "101% quality" mindset in you team before you get dividends.

If you haven't read Founders at Work, you definitely should. Reading this I've enjoyed every page. Probably this book is more about "experience sharing" than any other book. This book has 33 co-authors each sharing his insight into key components of success. I just could not resist posting these words of wisdom of Steve Wozniak:

Livingston: What is the key to excellence for an engineer?

Wozniak: You have to be very diligent. You have to check every little detail. You have to be so careful that you haven't left something out. You have to think harder and deeper than you normally would. It's hard with today's large, huge programs

By the way the whole interview with Steve is publicly available. Take your time reading it.

If you were looking for good high-level info on .NET 3.0 check out following whitepapers from Microsoft:

• Introducing .NET Framework 3.0
• Introducing Microsoft Windows Workflow Foundation
• Introducing Indigo (aka Windows Communication Foundation)
• Introducing Windows Presentation Foundation
• Introducing Windows CardSpace

These whitepapers give important information for connecting business and technology with respect to .NET 3.0.

Sun is going to release NetBeans, a popular Java IDE, under GPL. I'm not sure if this is good or bad and who will loose or benefit from this. And I do not see how making NetBeans "more Linux friendly" as stated in "Why GPL v2 FAQ" will make its users happier and the product itself more successful.

PS I'm not against open source. I'm against spending effort on activities that do not produce any value.

Don't take me wrong, but I'm convinced that software engineering is not about fixing bugs. Well, you have to fix bugs sometimes, but you do not have to that always. If you have product with no bugs, you do not have to fix them. All you have to do is build a product in a right way from the very beginning. From the time you've got the "Aha!" idea for a new piece of software. Think it's impossible? Have you ever seen civil engineers fix skyscraper after they've built it? I'm really surprised to see a press-release from INTSPEI entitled "Fix Bugs Early with INTSPEI P-Modeling Framework". If we are doomed to have defects in our software, then, of course, it is better to fix them early. But if we are not?

Recently my colleague and I were going from Kyiv to Dnipropetrovs'k by train. During the journey we had more or less comfortable seats and almost 6 hours of free time. When battery of my laptop ran off after watching the Planet of the Apes we started reading articles opened in many tabs on my colleague's FireFox. Here goes the list (not complete though):

• In Defense of Not-Invented-Here Syndrome by Joel Spolsky;
• Five things I hate about Emacs and Vim;
• Editor: vi or emacs?;
• How to Make Wealth by Paul Graham.

Do you think this list is random? I think not.

PS Check out the headline picture of Emacs and Vi. Wouldn't it with symmetrical picture fully describe the situation around Vi and Emacs?