No More ASP.NET

I have been writing a ton of software lately in C#, C++, and MCML. When writing software for the public, as opposed to writing for a client for internal use only, I tend to rely on tools more and more. This is especially true as a project comes to a close as my current project is. One of the tools I have come to rely on is MSBbuild. I was always accustomed to using plain ol’e Visual Studio to manage build projects; leaving those messy .proj and .sln files to the smart guys over at Microsoft. However, as my projects got bigger and things like deployment, testing environments of different clients, and tracking versions became more important, Visual Studio could not keep up. So I dove into the .vcproj files and found a treasure trove of useful stuff.

Then again, as I got even closer to product release, even MSBuild and .proj files (in their vanilla release states) fell short of my needs. The MS development docs give lots of info about writing MSBuild extensions for satisifying every development need. But sheesh… that is TIME CONSUMING. And with a big list of tasks to complete just to release my software products I was not willing to take on yet another time consuming project (that is, writing MSBuild extensions).

Enter pwelter ant the msbuildtasks project. This is a collection of custom msbuild tasks for just about every need from FTP to VSS to Zip. I downloaded and installed them and started using them right away.

Later I needed other things setting environment variables and code signing. msbuildtasks doesn’t do either of these. So I set about writing batch files and cussing at Microsoft for, yet again, removing features, shuffling things, and hiding useful stuff in documentation.

Then, by happenstance, I came across another MSBuild tasks project. I could have sworn that I did a thorough Google search for another project back when I found the original from Tigris. But, oh well. This new project, written by Mike Fourie and hosted as a CodePlex project called the MSBuild Extension Pack, handles both environment variables and code signing, as well as a host of other nice things.

There is some overlap in both of these projects, but they are both useful in their own right.

There is some disagreement on why software developers are, for the first time in 12 years, having a more difficult time finding jobs. The new C’est la guerre is “it’s the economy”.

Not true for software programming jobs.

Lots of jobs have been lost in the last few months, yes. Even several software programming jobs. But there has always been a shortage of programmers in the enterprise and many of those programmers leaving small and medium sized companies are landing in larger companies, healthcare, and government.

Another reason put forth is the growing number of expert software programmers coming online overseas (India, China, Middle East, and the Eastern Bloc). Some believe that competition is growing as American companies move software development offshore.

Not true for American programming jobs.

Offshore development is notoriously difficult. Even ONshore development is difficult. But contrast the trials of writing software with a team of people whom you share language, culture, slang, TV commercials, and cartoon experiences with to writing software with a team with whom you share NONE of this. Yes, exactly. It’s super hard. Much offshore development devolves into programmers writing “exactly what they are told to write” and no more, just to get something right! Offshore development is getting better, so we always hear, but it is not all its cracked up to be. And software programming jobs are not moving overseas in droves.

The real culprit is Microsoft.

Microsoft is in the business of democratizing access to software technology. In other words, they are constantly looking for ways to get more software into more peoples’ hands. As such, they lower the bar to writing software, thus making software cheaper. And, by extension, making software programmers cheaper as well.

This is a good thing, by the way.

By lower access to better software Microsoft is constantly increasing productivity. Contrary to what some would have us believe, money doesn’t grow on printing presses. Money is an exchange medium for productivity. In other words, we create money by creating useful stuff. Great software helps us create useful stuff more quickly for less. The problem is that real income for software developers has not increased in 10 years. Instead, incomes have remained steady while productivity has increased.

Oh, you may say, “Microsoft isn’t the ONLY company making great software.” And you would be correct. But the Microsoft Difference is that they are democratizing software. They consistently take expensive software (operating systems, database servers, web servers, etc) and make them inexpensive and easy to own.

“Yeah? What about the Open Source software movement?”

Don’t you mean Linux? Without Linux there would be no Open Source software movement. And, in case you didn’t know, without IBM there would be no Linux movement. IBM used Linux to lower the cost of Non-Microsoft operating systems in a bid to sell IBM Services. It was a huge investment for IBM that worked like magic. Linux spread like wildfire while Linux enterprise services companies like Red Hat reaped the benefits. So, the Linux Movement wasn’t a movement at all. It was a corporate plan hatched by IBM to keep IBM growing and profitable.

Now, as a result, more software programmers are hitting the market, younger, and better prepared for the enterprise. They are also less knowledgeable than before because they don’t have to know the “deep things” of software programming (memory and pointer management, storage management, drivers) required by earlier software programmers. Thus productivity is increased keeping software programmers prices steady and helping to create a shortage of jobs.

So thank Microsoft for both a thriving economy (in the thriving days), and a shortage of programming jobs (in scarce days).

And they’re not done yet. What Microsoft is unleashing on the software industry right now will not only increase the number of truly great software programmers, but will also cause far more competition for programming jobs than we see even now.

But now Apple is in on it.

I’ll write about that later.

When David Heinemeier Hansson created Ruby On Rails he didn’t know he was creating something bigger than a language platform. He didn’t know he was creating a movement, one that would help fill a gap in software dev that has been around since 2002. He had no idea that his simple straight-forward, and inflexible, way of creating software would challenge the largest software company in the world.

Hansson didn’t know he was creating a replacement for VB6.

It is counterintuitive to think that a UI-centric, inflexible, memory hogging, butt-simple dev platform could actually fill the gap for VB6, a um … UI-centric, inflexible, memory hogging, anybody-can-do-it, development platform. One would think that a VB6 replacement absolutely must run on Windows. But, when you really think about it, anything that would replace VB6 would have to have the following qualities:

• It must be easy to pick up and very forgiving
• It must have a large set of code snippets to pick from
• It must support real-world applications
• It must be web-based

Why must it be web-based? Well, because the Internet is the new Windows platform. Eventhough I like to poke fun at Internet Pontificators I am going to make a wild and outlandishly obvious prediction: within 100 years 80% of daily use software will be web-based. I didn’t mean web-enabled, but web-based. iTunes is web-enabled. One day it will be web-based. Technologies like Google Gears will make that possible. Once Gears-like functionality is the norm, there will be very little reason to distribute software that requires an install program to run.

Enter RoR.

The trend towards all-web-based-all-the-time (AWAT) was going to happen, but RoR is going to get us there much faster. By making web dev as easy as VB6 dev, RoR is giving all those old VB6 programmers who had to leave the development market a new lease on life, and accellerating the proliferation of the AWAT. Now you don’t have to learn all about OOP and MVC and other stuff like that. RoR takes care of all that stuff in the background; just like VB6 did.

Welcome back VB6 guys.

A wise man once concluded that there is no such thing as a free lunch. He was right, of course. Agile methodologies have promised programmers that they can build big software without big planning-up-front.

If Agile isn’t promising success without planning then what is it promising? If you can’t answer that then welcome to Earth.

Why is this a problem? Because Agile is selling a promise to developers that must be fulfilled by architects and designers.

Yes, the Agile practices of 2-week timeframe’s, daily stand-up meetings, pair programming, etc, depend on the simple fact that SOMEONE is keeping a clear vision of the end product in mind.

That sounds like BDUF (big design up front). Someone has to do it. It’s not the developer’s responsibility, it’s the architect’s.

So successful Agile development requires an architect to succeed.

A techtalk video of Hubert Smits, the Agile Guy, inspired this post.