The title of this entry is intended to be a bit controversial.

Controversy is required, as one of the thing that I've noticed in this industry over the years - especially as it tries to shape up and professionalize to combat offshoring - is the large number of otherwise brilliant people desperately clinging to whatever looks like best practices. Traditionally they would be called cargo cultists, but I don't think that really applies, as they don't really expect the planes and ships to drop off cargo (that only makes sense in the context of the linked analogy, which details a South Pacific tribe that, after seeing allied forces receive wonderful cargo from ships and planes, thought that dressing up and acting like the allied forces did, with straw runways and bamboo earphones, would magically make plane and boat loads of cargo appear for them as well. They thought that the process they observed was the important part, and the cargo was a secondary effect of it. I love that story as it is exemplified in so many areas of human behaviour).

Instead they simply want to look the part to the greatest degree possible, doing a good job where they can, but ensuring that no-one can question their decisions because they've deferred all rational judgment to the beating mantras of "industry best-practices". Patterns, code-reuse, frameworks, struts and MVCs, CRUD, n-tier, web services, process, and so on. I'm hardly the first to observe it, but in a couple of very large corporations I've watched whole divisions pursue efforts that everyone (and I mean everyone) knew would be detrimental in every way that they were supposed to help, but people were happy as long as it covered their behinds in the case of questions from higher up. This isn't just a culture of yes-people, but rather one where people will happily pursue activities that give the illusion of best practices, without ever questioning or understanding why it's a best practice, or whether it's really a best practice in their unique environment or niche.

One such "best practice" (there are many that I'm suspicious of, but I should probably keep this entry at least remotely focused) is the tendency of teams to accumulate, and advocate the reuse of, internal code. This is often done under the banner of frameworks, common libraries, component sets, and so on. The idea is that with this accumulated quantity of code, each new project will have a leg-up on the competition. Code in the library is considered an asset, and managers and owners like the idea that, while developing product A, as a side effect they're accumulating this great repository of generalized code which they'll be able to use for a completely different product - let's call it product B. Soon the domain knowledge of their developers won't matter (and thus they'll be expendable), because everything is encapsulated in common code: They've codified the abilities of their team.

This couldn't be further from the truth.

The greater the bulk of code you accumulate, the more intrinsically you tie yourself to your current developers (and the more they occupy their brain with information that is only applicable in one organization or team), and the more difficult it will be to bring new developers online. Such frameworks and libraries often come with enormous learning curves for new hires - especially as documentation is virtually always ignored - and they can seldom be reused for anything else without significant refactoring (because they likely weren't truly designed for reuse, or they were in only the most arbitrary and superficial of ways. I think every developer can empathize with being told that they could "just use our library X to do that", to find that it offers nothing remotely like the promised functionality, so the developer is then tasked with not only building the functionality, but building this single-use functionality in a manner consistent and generalized for the library, despite it being unlikely to serve any purpose for anyone else, ever).

The question every organization needs to ask itself, then, is what value they could sell their "reusable code" for - what, realistically, would competitors and new entrants in the field offer for it? The answer, in almost every case, is $0, and they wouldn't want it even at that price. There is extraordinarily little code theft in this industry (even though we're in the era of burnable DVDs and USB keys) because most code - above and beyond the industry-wide frameworks and libraries - has no value at all outside of a specific project with a specific group of developers. Trying to use it for other projects is often worse than starting with nothing at all.

Perhaps I'll augment these thoughts, and refine them further, in the near future, but a couple of bullet points should convey the basic premise.

• The statement "I believe in code reuse" is nonsensical. We all believe in code reuse, where appropriate, but it isn't an all encompassing mantra. It doesn't make you a better developer beating your chest with empty statements about code reuse
  
• Code reuse doesn't happen by accident, or as an incidental - reusable code is designed and developed to be generalized reusable code. Code reuse as a by-product of project development, usually the way organizations attempt to pursue it,  is almost always detrimental to both the project and anyone tasked with reusing the code in the future
  
• Internal code reuse for niche industries and domain specific problems can be very valuable, but code for generalized, industry-wide problems are seldom valuable unless you're truly developing it for industry-wide consumption (e.g. the .NET Framework is tremendously valuable code reuse). I have seen too many examples of large internal libraries that are largely duplications of vastly superior functionality existing in the .NET Framework or C++ Standard Template Library, or which could be better served by available professional or open source libraries. If your problem isn't domain or niche specific, but rather is industry wide, it is extremely likely that either a library encompassing it exists, or that it isn't a problem that is worthwhile generalizing
  
• Always reasses your internal code, and continually compare it against what is available in the field. For instance if you've abstracted some data access, maybe you should look at the Microsoft Data Application Blocks (there are countless developers who know this framework, and it has been heavily vetted, versus a couple of developers internally hacking out their own data framework). Perhaps you can replace your internal encryption library with something that is industry wide. The goal should always be to minimize the amount of code in internal libraries to that which truly gives a strategic or tactical advantage, leveraging the talents (and agility) of the industry to the greatest extent possible.

In the end there are some wonderful examples of brilliant code reuse out there, but there are also a lot of terrible, horrific, productivity destroying monstrosities. How many projects have been led awry when the first task, before the product is even understand or any sort of requirements gathered, is the ever nebulous "build a framework" task...

I got an excellent email from Ruud Steltenpool offering another perspective regarding the current state, and future, of SVG. I think this topic deserves a balanced treatment, as many of the readers here are only partially aware of what SVG is or how it applies. With Ruud's permission, I've included the exchange below (this was just casual banter between us, so manage expectations of perfect grammar and structure accordingly. The email starts at the newest message, going back through my reply, to Ruud's original email).   

---

-----Original Message-----
From: Ruud Steltenpool [mailto:svg @ steltenpower.com]
Sent: September 15, 2005 7:01 PM
To: Dennis Forbes
Subject: RE: SVG is Dead! Story at 11!

Thanks for the reply Dennis, (just call me Ruud) and a very good day to you too.

Go ahead posting, even though i found some things that could've been written  a tad more elegantly and some typos, i don't think it really needs changing.
And here are a few more somewhat loose bits:

The executive summary is very much about money.
SVG is about freedom of creativity...... , [[[[[sidestep example: SVG is a great way for 'coders' and 'clickers' to cooperate. A 'clicker' just hits "save as SVG" in their own favorite graphical tool and generates something a coder can easily work with in their own favorite editor. Some coders can actually think of things that look good, but can't handle a pen/brush/mouse and some are amazingly good at realizing the idea through coding instead]]]]]] ............... which makes SVG a tough sell.
It's related to that not many people know/understand/believe that you can actually make money (some companies are making loads of money actually) with free software. My attempt at grasping it http://steltenpower.com/OS4entrepreneurs.pdf

Nobody really puts a marketing budget behind SVG (yet), cause nobody owns it, nobody directly makes money off selling SVG. So no millions of dollars making sure we all hear about every 'superduper fantastic major' product the technology is used in. Perception is indeed important. Many people for example think that anything that moves in a website is Flash. Some of those just blindly clicked "Accept" once and are watching SVG instead some of the time. And with all major browsers except for IE doing some or a lot of SVG out-of-the-box now or very soon, there will be a lot more people thinking Flash while looking at SVG. Things are changing though, for
example: Though many brands are offering phones with SVG pre-installed, only just recently Sony Ericsson was the first to decide to actually mention it to their customers in the description of the many models.

Good thing you mention Google. I've used it extensively for anything related to SVG. And in the last year and a half a lot has changed on the web. First you would find a lot of the 'SVG is perfect for everything and will change the world tomorrow, starting with bringing world peace' kind of articles written years ago. Though these articles are still there they are a minority now. What i keep finding is articles on a very broad spectrum of subjects, with somewhere between the lines saying SVG.
Sometimes with "(Scalable Vector Graphics)", but usually nothing more than those 3 letters, no explanation, nothing. I think that really says a lot, it's used as nothing special, as the natural way to go.
And more specifically on Google, they used to not index SVG-files: now they do. And the Open Clip Art Library probably gets a lot more traffic since. On Google Maps: Jim Ley just showed on svg.org how to get SVG in Google Maps.
Google might just add SVG, probably silently. Maybe a bit after Mozilla
1.5 final (it's in beta now), or what about the mobile market, that is more bandwidth-limited ?

And on raster images being good enough: Often they just are, nothing wrong with that. SVG can and will also be used for things that are just plain annoying, the things we have Flash-blocking extensions for. And of course some of those rasters are already being created with SVG and if based on browser-sniffing they are partly replaced with the original vectors not many people will immediately notice it.

SVG sneaks up on you, no big bang, no explosion, though the hype years ago tried to make us believe so.

I'm not so sure of Adobe moving away from SVG. Microsoft will definitely try some usurping (don't forget many, many people use ancient versions of Windows, so don't expect to see things changing fast on that end. Just as with SVG, things just take time), but will have a hard time, even more when Adobe turns up a plug-in that does SVG+Flash+PDF tomorrow :-)

As you would like to have this 'discussion' appearing on the web, get yourself some more traffic with posting a link at svg.org

Regards,

Ruud

On Thu, September 15, 2005, Dennis Forbes said:
A very good day to you Mr. Steltenpool! Thank you very much for the
feedback
- it is very much appreciated.

Firstly, let me say that I love SVG - I think it is an elegant,
extraordinarily powerful, vendor-neutral solution. When I write about
my perception of its demise (or continued irrelevance), I don't do it
out of malice or dislike of SVG, but rather sadness at the way things
have turned out. I think SVG is one of the most underrated technologies out there.

Outside of that, my work schedule and focus has definitely been in
places other than SVG for the past while, so the truth is that I'm not
entirely attuned to all of the happenings in the SVG world. Instead
I've been watching the "Executive Summary" version of the happenings
in the SVG world.
E.g. while there are lots of small progressions and improvements in
the world of SVG, from outside looking in, it is a technology that
completely stalled. I absolutely believed that SVG should have
EXPLODED into the marketplace years ago, enabling a whole new
generation of dynamic and gorgeous interactive web elements, but
instead here we are today with an SVG use and saturation largely where
it was (or declined) three or four years ago. The market is seldom
rational, and it looks like most developers (who are the ones who
would drive this sort of technology) saw Flash, or even raster
graphics, as "good enough". I completely expected the open source
community to go nuts over SVG, and to embrace and adopt it
pervasively, but instead the SVG fork of Firefox (I've been trying it
on occasion for a couple of years) has been maintained and embraced by
just a couple of people, and many in the open source community simply
have a "bah, Flash is good enough" attitude. Now that Adobe is
inevitably going to continue to turn away from SVG, and Microsoft is
going to usurp the vector graphics community with their offerings, I
think the window for SVG to make a bang has passed.

I entirely agree that the flash specification in no way equals the
openness of SVG, and the restrictive clauses are onerous, however my
point was that it is "good enough" for many developers. Already when
advocating SVG I've been met with retorts that the Macromedia spec is
"open" as well.
Perception
matters more than reality, and the perception is that Flash is now an
"open"
standard.

At this point, the only way I can imagine SVG really making a serious
impact in the marketplace, and to become a general technology, is if
Google adopts it. If Google Maps, for instance, used SVG as the
underlying technology, it could catapult the technology. That's pretty
speculative, though, and I don't think Joe WebDev can rely upon that
when deciding on technical platforms.

BTW: Do you mind if I post your comment to me, and my reply to you? In
fact if you reply to this with corrections and clarifications, I will
post the thread from your reply on, giving you the last word.

Thanks and have a very good day

Dennis W. Forbes

-----Original Message-----
From: Ruud Steltenpool [mailto:svg @ steltenpower.com]
To: dforbes@yafla.com
Subject: SVG is Dead! Story at 11!

Dear Dennis,

On http://www.yafla.com/dforbes/2005/09/13.html :

I read an article on your website with the same title as this e-mail.
I'm not sure what you mean with "Story at 11!" (maybe cause i'm not a
native english speaker), but my best guess is "11 a clock" where 12 a
clock means really the end of SVG and my second best guess is that
it's some sort of expression meaning that you're joking.

Cause it is somewhat funny that your article shows up almost exactly
at the same moment as yet another big and important step in spreading
SVG even more. I am typing this in webmail from my Mozilla Firefox
with standard native SVG rendering, that was released just days ago.

It sounds like you're not very aware of how much SVG is being used in
the world. Some of your remarks are at least inaccurate:

Batik just introduced sXBL implementation (just after your article
though)

Flash is not as ubiquitous as MacroMedia likes to make us believe.
I believe it's on a lot of desktops, and i believe a lot more (than
SVG) BROWSERS are equipped to play Flash through a plug-in, but i
don't believe these numbers. "Lies, damn lies, statistics" And SVG is
used in lot more
places: big applications using it through Batik or other toolkits, KDE
using it for icong and wallpapers, Inkscape, the OpenClipArtLibrary
and Scribus getting more popular by the day for a reason.

Didn't you see that the Flash File Format comes with a restricting
license?

And on Adobe, well Kurt Cagle blogged on that very nicely:
http://www.understandingxml.com/archives/2005/08/on_adobe_svg_an.html

The mobile market is huge and compared to SVG, the use of Flash is quite
.. ehm..  Tiny :-)   Even though MacroMedia might be screaming all sorts
of things of the roofs (i don't know if that is a real expression in
english), i see more and more SVG phones showing up, really in the
hands of people, and services of for example Vodafone, the biggest
provider in the world, using the functionality.

Microsoft will indeed keep capturing something for quite a while, but
someday they have to start indeed capturing hearts, cause people are
starting to only spend money on things they fully like (and combining
with other tools is just too great a feature to miss).

And on the server, there we'll be running XAML to SVG transformations.

It's just the "open" movenment, a big force of cooperation, that
MacroMedia , Microsoft or whatever company cannot stop. They're
welcome to join though
:-)

Anyhow, i hope you're happy to hear this good news on SVG. Your
article managed to get me away from coding some SVG actually :-) That
will have to wait till tomorrow cause i'm falling asleep.

Maybe see you at SVG Open 2006? I'll buy you a drink

Ruud Steltenpool
organizer of a well-attended, fruitful and fun SVG Open 2005

In yet more SVG-related news, Microsoft demonstrated tools it's building for its SVG marginalizer - Sparkle. You can see more on Channel 9. I came across this on Slashdot. It appears that they're talking about Microsoft Expression, which I linked in the SVG discussion.

After reinstalling Visual Studio 2003 (while I could try diagnosing every single possibility, I just needed the machine up and running as soon as possible), the problem persisted - "Could not create automation server" whenever I added a project to a solution, failing the operation. Somehow something was broken during the process of uninstall a prior CTP of SQL Server 2005 (and the .NET 2.0 runtime), and installing the newer version.

In any case, I eventually tracked it down to the scripting engine being broken, so I downloaded the 5.6 scripting engine. Of course the MSI was blissfully unaware, and thus belligerent towards, Windows Server 2003 (which I use as a development/test workstation), so I had to run it in an XP compatibility mode, but that solved the problem. This is entered in the archives just in case someone in the future has this problem.

I've unintentionally come across this website several times (today I had a need to reference a double-slit experiment), and each time it has sucked me into meandering through its excellent interactive demonstrations. While this is high-school level physics, if you haven't brushed up in a while it can be eye-opening and educational. The site appears to have been designed some time back, and aesthetically it is subjectively rather dated, but it is pure genius the way it uses interactive elements for education - This is the sort of thing that demonstrates computer and web learning at its finest.
 
Irony (or is it?) - Mental confusion over how to spell genius ("Genious? Hrmmm...")

This entry doesn't really relate to software development, but nonetheless it covers human behaviour and subconscious decision making that does significantly impact our marketplace.

Here in Canada, a year or so ago there was a big kerfuffle in the federal government concerning transfats - a controversy that got a tonne of press (both by boosters encouraging this consumer protection, and critics who decried it as the actions of a nanny state). Namely, that there were calls to ban transfats from the food system, legally eliminating this purportedly dangerous, artificial fat from grocery shelves. This would have made us the second country, after Denmark, to ban transfats. Transfats are, of course, the hydrogentation of otherwise normal, in-moderation-healthy unsaturated fats, molecularly altered to improve handling (hydrogenated oils are solid at room temperature, and in fryers need to be changed less frequently), and reduced spoilage and possibly consumer convenience - goods stay "fresh" on grocery shelves for longer, while baked goods made with transfats, for instance, often stayed bizarrely fresh out of the package for days. Humorously, a couple of decades ago transfats were seen as the saviour from the evils of saturated fats.

While McDonalds, along with the other big fast-food companies, are addicted to transfats, and they're finding it difficult to cut their use of the stuff, I've been noticing more and more formulation changes on store shelves - I've always been a label reader - with transfats being voluntarily eliminated from whole categories. Occasionally this change has occurred silently (there was a mass migration from trans-fats in potato chip products about a year ago, with only a few of the companies actually noting the dramatic health benefit change), while in other case it has come with a huge marketing campaign. Even for those people blissfully unaware, the quantity of transfats in their diet has plummeted, apart from a couple of hold-outs like McDonald's french fries.

So why has this mass change occurred? I suspect two reasons:

• The publicity relating to the debate brought this to the attention of the public, and the public started to subconsiously (or consciously) associate transfats with bad things. This subconscious association is enormously effective in altering behaviour at the root level. Children's treats like Goldfish, which used to be made with hearty amounts of transfats, were suddenly like handing your child a pack of cigarettes, which obviously is unacceptable to parents. The Goldfish company, after switching to a transfat free recipe, claimed that they did it out of the goodness of their hearts, and there was little public demand. I suspect that they are being disingenuous, and they knew that their marketshare would disappear if they didn't accommodate this new health information.
• Legal concerns. Now that everyone knows that transfats are dangerous, and we know that alternatives are possible, food companies are building themselves a massive liability risk with every transfat laden product they ship. It's one thing to rely upon them when there is ignorance, but quite another to turn a blind eye to their dangers when it has been well documented. I suspect a lot of the silent switching has been to limit future legal threats.

Interesting seeing the impact public information, and the future threat of lawsuits, has had upon such a huge part of our marketplace. And in such a short period of time! Government intervention was entirely unnecessary (and might actually have slowed the switch, as what should be a simple health debate would inevitably turn into a bunch of partisan nonsense, with the opposition party and boosters sucking back a tub of hydrogenated oils in the name of freedoms, proclaiming the rights of all Canadians to eat transfats. Such political nonsense is typical in those scenarios, regardless of who is in power and who is across the floor).

Brad excited by what he saw at PDC.
Brad Feld, venture capitalist: 2006 Will Be The Year of Microsoft.
[Scobleizer: Microsoft Geek Blogger]

A surefire way of getting linked on Robert Scoble's highly rated and ranked blog is to say something promising about Microsoft, or to say something negative about Microsoft in a way that Mr. Scoble can easily defuse while pretending to agree with you (such as http://radio.weblogs.com/0001011/2005/09/16.html#a11174, where Scoble subtly claims that Balmer was being misinterpreted). In this case, a VC was drunk on the PDC, and like many before him presumed that everything Microsoft spins is gold. Many foolish predictions have come out of such a situation.

In any case, while Microsoft will continue to do very well by any definition, it's quite a stretch to call 2006 the year of Microsoft.

• SQL Server 2005 and Visual Studio 2005 will barely be out of the gates, having come out (hopefully) at the end of this year - I believe early November. It will be quite some time before legacy shops (which are of course the bulk of SQL Server customers. The RDBMS market isn't a heavily expanding market, and is largely selling to existing customers or trying to steal customers from your competitors) will upgrade their SQL Server installs, especially given the large schism to 2005. Visual Studio 2005 is a great product, but it's largely an upgrade/maintenance release for the existing Visual Studio base, a large percentage of which are on the MSDN program anyways and thus will upgrade at no revenue advantage to Microsoft.
• Vista will see adoption among the leading edge, and of course will replace XP on new PCs (to no gain to Microsoft), but it will see negligible adoption in corporations. Many corporations haven't even modernized to XP at this point, 4 years after its release and despite it being a minor difference from 2000. Vista represents a pretty large transition.
• Office 2006 is similar to Vista - it'll take years to see heavy adoption in the corporate space, and otherwise will largely be sales to new buyers (who will just be getting 2006 instead of its closest competitor, Office 2003).
  
• Many of Microsoft's new technology platforms will see negligible adoption in the first, and even second, year. This is just experience talking, but there is a long list of examples of highly lauded Microsoft technologies that struggled or saw little adoption for years (.NET being an excellent case. By now we were supposed to be awash in .NET applications. While it is a superlative web platform, and was a critical upgrade to classic ASP, the desktop world has been barely impacted by .NET at all, against most predictions)

Undoubtedly Microsoft has some great products, but we're talking about a company that needs to maintain a revenue of $10 billion a quarter, and with programs like software assurance and the MSDN program, these upgrades are long overdue. If anything, these releases are about avoiding a loss of revenue stream rather than an increase of revenue stream.