With some amusement and a good chunk of confusion, I've been following the ongoing debate between Jeff Atwood/Joel Spolsky and Uncle Bob Martin.  I won't bother detailing the argument; if anyone reads this blog, they probably are already aware of the salvos launched by each faction (I ran out of words for the last link).  My befuddlement stems from the fact that the two sides really aren't that far apart.  It seems to me that it would be rash to say that either Atwood or Spolsky completely believes that proposed guidelines like Uncle Bob's SOLID principles are a bad idea.  And I'm fairly certain that Uncle Bob has respect for the idea that the Liskov Substitution Principle might be a little hefty for a novice developer to understand in their first years in the market.  After listening to Hanselman's podcast with Bob Martin on SOLID, I am convinced that Mr. Martin, though he completely stands by his guidelines, is aware of the complexity that these principles present at first blush.  The main similarity between the two arguments is that both Atwood (Spolsky has kind of ducked out of it, and I don't blame him) and Martin are going about laying out rules for developers the wrong way.

Atwood maintains that " Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off."  And I agree with him.  There are, unfortunately, a lot of terrible programmers out there polluting our sacred pool.  But, there are even more programmers that don't have time to pay attention to blogs, read "seminal" books on design patterns and programming theory, and prototype all of the hot new ideas as they come out.  I've only started getting into NHibernate, even though ORM's have been around for years, and I don't count myself in the ranks of "terrible programmers."  To be frank, I just haven't had time to learn about it.  And I've found that a lot of programmers are like me, they don't have time either.

I have a colleague that is busier than I am.  He doesn't read blogs, doesn't go to trade shows or user groups, doesn't read books, but he's still a good developer.  And he wants to learn, it just doesn't always fit into his schedule.  As we have worked together, I've come to realize that one of the biggest barriers that he faces consists of the large wall created by acronyms, buzz words, and high-brow conceptual language that make no sense until you have a chunk of time to study them.

Software development is a complex science, without a doubt.  But when we create jargon to appease our programming nobility, we not only make it difficult to sell new ideas to the managers and decision-makers in our enterprises (not all of us have the good fortune to run their own company or work for software companies), we also create knowledge obstacles for the programming bourgeoisie. Ninety-eight percent of the development work-force does not have time to keep up with SOLID, TDD, FDD, DDD, ORM, DRY, YAGNI, AJAX, MVC, MVP, Agile, XP, RAD, MEF, Clouds, WPF, WCF, WF, ECM, NAMBLA, POTUS and WTF.  My colleague may have been creating class instances dynamically for years without knowing that he's been using the Factory Pattern the whole time.  He knows what works, what's fast, and what's scalable and easily maintainable, and frankly, he doesn't give a flying fuck about patterns and practices and principles and acronyms.

As a lead developer, I very much am concerned with patterns and practices.  But my main concern at this point is not keeping abreast with the latest theories, its finding out what works for our enterprise and figuring out how to help my peers understand why they should use it.  And in this effort, I have found that buzz words and acronyms don't do me a lick of good.  What does?  Easy-to-use documentation and code samples.  That, my friends, is how you sell software developing ideas. 

So it was quite amusing to me that Jeff's rebuttal to Uncle Bob was yet another set of acronyms, even if they stand for very simple concepts.  A lot of these terms make sense to me because I've taken the time to study them.  Terrible developers are staying terrible because the nobility has stopped talking to them.  They are too busy talking among themselves in a jargon that few others have the time or inclination to understand.  Keep it up, guys.  I'll keep trying to edit and translate.  

As I've continued coding in VB.Net at my new(ish) job, the "WTF!!!" factor has reduced substantially, although I still do a lot of backtracking to insert Dim statements.  For the most part, I've realized I can do all the same stuff in VB that I did in C#, along with a couple of nice things like the great pile of VB snippets that ship with Visual Studio compared to the meager offerings for C#.  Don't get me wrong, I'd still rather be coding C#, but I've come to terms with the fact that they really are the same thing when it comes down to the CLR, and except for a few small differences, it's really just a matter of personal preference.

Or is it?

It's certainly not my personal preference, in this case.  So I guess it's enterprise preference.  But wait, who decides enterprise preference?  Someone obviously does, someone who probably makes a helluvalot more money than I do, and probably doesn't code any more if they ever wrote code in the first place.  What I've been wondering lately is this: if both VB and C# compile and run on the same .Net runtime, why do enterprises care which language its developers use to write .Net applications?  Just because I've been coding VB for the last three months doesn't mean that my C# skills have atrophied off like an unused extremity.  I can still read and write C#, and when I coded C# for a living ("enterprise standard" at my old job) I could still read and write VB.  Once folks understand the simple syntactic differences between the two, square brackets for arrays, angle brackets for generic type identifiers, "Dim thing as type," Function and Sub, etc., it's really not hard at all to read and understand both.

The common answer I hear to this question is that the enterprise wants everyone coding in the same language to...

1. Promote code reuse.
2. Make it so that if department A happens to be on a team building exercise at the archery range and they all get impaled on crazy boomerang arrows, department B can "seamlessly" pick up where the dead folks left off.

 

Superficially, these reasons make a lot of sense.  Code is easier to share and recycle if it's all in the same language.  Joe Developer coding VB in the Wonky Department on the 12th floor can read Jane Developer's code, even though she works on entirely different stuff in the Hinky Department on the 3rd floor.  And that's good, because Jane wrote a really cool snippet for connecting to the company mainframe and screen-scraping something or other.  But wait...why does Joe even need to read Jane's code?  It seems to me that if Jane wrote that functionality in C#, she can simply bundle it up into an assembly, compile it, and offer it to Joe as a referenceable DLL. 

All Joe sees are the members of Jane's object after he references, and Visual Studio translates that to VB for him anyway. 

 

Joe doesn't even see "public string CSharpMethod(string inVal)."  Pretty nifty runtime conversion there, if you ask me.  Another example of the inherent quality built into the Visual Studio IDE.

Can somebody please tell me why I can't write my applications in C# even though my boss wrote applications in VB?

I'm in the process of re-learning VB.Net.  I started with VB a long time ago, moved to C# with a career change, and now, due to another career change, am switching back.  I am unhappy about it, but am trying to keep an open mind.  Today was one of those days where my open mind slammed shut. It was a situation similar to my first aphorism.  I had an array that I needed to get into a List<string>.  This time, however, the array was of an object provided as a return value from a method in a referenced API.  And the string I wanted to put in my List was a property of that return object, not that object itself.  Here's the long way:

Dim vendorAPI as new Vendor.API()
Dim things() as Vendor.API.Thing = vendorAPI.GiveMeThings()
List(Of String) stringsFromThings = new List(Of String)()
For i as Int32 = 0 to things.Length
   stringsFromThings.Add(things(i).StringField)
Next

I knew there had to be a cooler way to do this.  So I dinked around with it a bit, being rusty with VB and having never known these new tricks when I was writing in VB anyway, and couldn't figure it out.  With a little help from Kevin, I was able to Lambda-ize it in C#:

List<string> stringsFromThings = 
   things.ToList().ConvertAll(t => t.StringField);

Lovely, isn't it?  So I set about trying to do the same thing in VB, and so far this is the best I can come up with:

Dim stringsFromThings As List(Of String) = _
   things.ToList().ConvertAll(Of String)(Function(c _
      As Vendor.API.Thing) c.StringField)

After another day of cussing every time I tried to declare something as "Type varName" instead of the banner-of-VB "Dim varName as Type," I felt a little disgusted.  The main problem I have is that the VB compiler doesn't seem to have the ability to interpolate the type of "c," even though "c" has to be of type "Vendor.API.Thing."  And I'm still getting over the syntax thing, of course, but hopefully my open mind will open more.  If there's a better way, please tell me. I feel more like Wordsworth than I ever wanted to.

At the risk of unsettling others that have talked about poetic code, have URLs with the post-title I originally wanted to use, or have even gone so far as writing a book on the subject, I'd like to talk about the beauty of code.  Not all code, not just any code, but lines of code that get the job done artistically.  Sometimes it involves thinking in a way that logically short-circuits the kind of spagettastic novellas encouraged by bygone paradigms like VB6.  Other times, it's using language features to accomplish something with unusual elegance.  Sometimes, lines of code are just really neat.

As I said above, lots of people have talked about this before, so to take a stab at semi-originality I've chosen the word "aphorism."  By definition, an aphorism is generally used on a cultural, moral, or ethical level, and applies to verbal language, like a saying or adage.  For example, Jesus was full of aphorisms.  I like this word, and this is my post, so I'm going to selectively use the definition to apply to computer programming, as "a terse [passage of code] embodying a general truth [or principal]," where "truth [or principle]" is an operation, action, or necessity.

When I first started writing .Net code in C#, I would often try to smash several lines of code into one line.  The Visual Studio IDE can get pretty nifty with IntelliSense in C#, and casting or adding another dot after a method call yielded many lines of code like this:

regKey.SetValue("Reg Key Name",
  ((CustomConfigurationSection.CustomElement)loadedConfig.
  CustomElementCollection[cmbElementKeys.SelectedItem.
  ToString()]).CustomElementString);

*This is all one line.  Line breaks added so things look clean and neat.  My OCD overfloweth.

Looking back, that line of code isn't really a bad thing, but there's a lot of crap in it, which makes debugging a hassle.  I've aged as a C# programmer, and I've definitely aged as a debugger.  Lines with a ton of implicit fields, casts, and especially multiple operations make the bridge of my nose hurt.  I still write lines of code like this from time to time, but I certainly don't have the starry-eyed appreciation I had for them when I was a wee lad.

Instead, I've grown really fond of fancy semantics and figuring out how to do stuff ways that I haven't done them before.  Hence, I've been busy trying to find practical application for the host of new language features that are included in .Net 3.0/3.5.  Recently, I switched jobs.  Before leaving my old position, someone on my team asked me to fix the exception handling in a class I wrote a few years ago.  As I barfed my way along (I have trouble looking at my own code from years past), I found a chunk of code that posted to a Java servlet in order to do an image conversion.  I had recently learned that the servlet itself, when it failed, would sometimes return raw HTML describing a Javascript alert.  Since the class runs in a multithreaded application driven by a Windows service, whenever this happened, the error returned from the servlet not only didn't get handled, but the application continued running as if everything was fine.  I set about attempting to fix this.  

As part of the exception handling, I needed to pump the stuff from the alert into the application's logging.  System.Net.WebClient.DownloadData() returns a byte array which, when the error appeared, had to become legible.  I thought I'd cram the byte array into a char array and then toss it all into a StringBuilder.  The old me would have muddled around for a bit trying to find a good way to do this, shrugged, and then written this common snippet:

byte[] responseData = webClient.DownloadData(uri);
char[] charData = new char[responseData.Length]();
for(int i = 0;i < responseData.Length;i++)
   charData[i] = Convert.ToChar(byteData[i]);

Sure, it works fine.  It's just chunky and unwieldy and it seems like there should be a better way.  Since I was upgrading the code from 1.1 anyway (big corporation=slow adaptation), I checked the Array namespace for something cool and found Array.ConvertAll<T1, T2>.  Then I realized I could use an anonymous method with the conversion itself, like this:

char[] chardata = 
   Array.ConvertAll<byte, char>(byteData,
   new Converter<byte, char>(delegate(byte c) 
      { return Convert.ToChar(c); }));

I did a small victory dance when this worked.  But the true aphorism only surfaced when I realized that the anonymous method could be further contracted into a Lambda:

char[] chardata = Array.ConvertAll<byte, char>(byteData, 
   b => Convert.ToChar(b)); 

That, my friends, is some sexy frickin' code.  Thank goodness for the freaks on the C# language team that think of this stuff.  With their help, every now and then I get to feel like Jesus.

Quick post to give a shout-out to Karl Seguin for his recent "Back-to-Basics" articles on CodeBetter.  He's done two so far, the first on generics and the most recent on delegates, anonymous methods, and Lambdas.  Karl does a really nice job of writing these posts in a manner that isn't condescending, yet explains the basics of these critical concepts for advanced development.  Good examples, good summarizing, good work!

Author/Editor Note: Originally, I thought this post would stand on its own. But after reading it again, it's become apparent to me that this is more of a rant than anything useful.  I will be writing follow ups in the future on the OOTB Compromise and vetting OOTB products.

A while ago, my cube-mate at work (we have double-cubes that make us feel all the more disrespected, even though I like my cube-mate) was forced to devote all of his time to building an application with an "out-of-the-box" piece of vendor software.  A few months earlier, he had received a bonus for "Technical Innovation," rewarding him for an excellent framework he had written to update the way we retrieved content from our ECM system. I called him "The Innovator."  Working on this new application, he became "OOTB" (pronounced ootbah).

Life was difficult for OOTB.  The project suffered from massive scope-creep, and the project manager had consistent problems communicating requirements, which often forced OOTB to have to redo pieces of the solution.  But the biggest obstacle was the vendor software itself.  Its intent was to provide a simple way to organize a Java-driven UI sitting on top of a business process workflow.  The workflow processes "cases," which are comprised of faxed documents for various transactions.  The basic concept is good: map UI controls to fields and decisions in the underlying workflow.  The implementation is sorely lacking.  Rather than a WYSIWYG editor, the vendor offers an MMC snap-in with loads of configuration requirements.  All of this configuration information is ultimately saved to a "metastore," which manifests in a convoluted Oracle database.  In order to make the workflow information available to the MMC snap-in you have to run an import utility; essentially an open file dialog with an "Import" button.  To operate on different deployment environments (Dev, Integration Testing, User Acceptance, Production), you have to manipulate (manually) a series of registry keys.  I can go on and on.  The bottom line is that the end-user functionality of this software is laughable.

OOTB attempted to put a good face on this, but kept running into fundamental design flaws, along with plenty of niggling little problems that drove him nuts.  He stopped shaving and started listening to old Slayer albums all the time.  He worked long hours attempting to configure user-interface functionality that would have taken him a fraction of the time in ASPX pages.  The client continued to throw curve balls, and OOTB kept having to stretch into more ridiculous positions to catch each wild pitch.  In the midst of it all, on his own time, he designed a beautiful framework that would have allowed the entire system to be coded and deployed in very little time, compared to the several-hour-long deployments he faced with every design change.  I'm pretty sure that the time he took to architect this framework kept him from killing someone.

Months have gone by, and through some magnificent mystery of corporate reorganization, I have become OOTB.  I inherited this project.  Having heard all of Original OOTB's complaints, I embarked on the project with a "C'mon, it can't be that bad" mentality.  Oh it was, and still is, that bad.  I've grown a big, bushy beard and spend my days listening to music that would make grandma cry.  But, instead of doing something productive, like design a framework for the way this thing should work, I'm writing this post instead.

As a developer, I can't count the number of times I've been asked by my higher-ups to look at a piece of software that is supposed to solve all of our problems with out-of-the-box functionality.  This amuses the hell out of me, since I'd be out of a job if these things actually lived up to their marketing.  Think of a world where software developers dance on the streets with organ-grinders, where monkeys wear business casual and spend their days pointing and clicking and dragging and dropping.  This will never happen, of course.  Not because all of us developers would get jobs making the OOTB software, but more because every time I've been asked to evaluate OOTB software, it never does everything we need it to do.  Some vendors promise improved functionality in future releases, others ignore you or look at you like you're crazy.  Some are smart enough to offer good APIs, others go so far as to sell you their source code.  No matter what, good software companies realize that they can never offer everybody everything they want, and good software companies realize that they must, somehow, give the users what they want.

The frustration for management-types that are trying to trim their budget fat is that they don't understand why we need all of these developers around.  "Why can't we just buy some software and hire some hourly people to do this instead of paying x developers y salary?"  Developers are the first people they target.  We're socially awkward, expensive, demanding pains-in-the-company-ass, and it's very, very simple to see us as overhead.  Vendors market their software as magic programmer bullets, and with this viewpoint in mind, it's easy to see why management might be quick to sign the purchase agreement.

A good application development team understands that repeated tasks should be consolidated into reusable code.  This takes more time up front, but saves gobs of code in the long run.  When OOTB software is brought in, there's a pretty nasty honeymoon as well, what with installing, distributing, and learning to use the software.  In the end, a well-designed, custom-coded solution is going to serve the enterprise better 100% of the time, because it directly addresses the needs of the business.  The OOTB software may make it easier to set up 95% of a solution, but I tell you, that remaining 5% is going to slaughter your bottom line.  So, in the end, why do enterprises sink so much money and time into pushing square blocks through round holes?

Probably because OOTB stopped wearing deoderant.

Coming soon: The OOTB Compromise.

 This morning I fired up Google Reader and was excited to see this post on DotNetKicks about a new "Image Generator" control in ASP.NET 3.5.  I do a fair amount of image manipulation for my current position, and displaying images to clients is always an issue.  Currently, we're using a Java viewer that works nicely on the client, once it's been finally loaded in the browser.  Unfortunately, the load time is prohibitive, what with a nearly 1.5 MB download, not to mention the time it takes for the JRE to fire up and load the plugin.  So I'm always on the lookout for new ways to display images in a browser.  This tool is advertised as a "speedy way of generating, transforming, caching images in ASP.net."  All right!  I've worked with several APIs that are available from various vendors, and though a couple of them have solutions that are quite good, a freely available tool would be great.  I hurried over to CodePlex and downloaded the assembly and examples.

One thing I always find strange about downloading stuff from CodePlex is that I often have trouble figuring out where to put it.  Like many developers, I'm sure, I have a huge directory tree packed with all of my code, which is organized to me, but would probably be impossible to dig through for anyone else.  After downloading, I attempted to drop the assembly into the GAC, but got the ubiquitous "Assembly <xxx> is required to be strongly named" error.  OK, then.  I settled on creating a "strongly named" folder in my code-maze, dropped the DLL into it, and created a website project to play around with it.  Then I remembered the sample projects, and happily using my new two-monitor setup at work (finally!!), I opened the example "SimpleGeneratedImage" website on one monitor and my test project on the other.  After jockeying the referenced assembly to get it pointed at the right file, I F5'd the example project and was a little startled to see this error:

Could not load file or assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Hmmm, I don't see that reference anywhere.  Ah, there it is, in the web.config.  OK, what the hell is that guy?  As you can probably tell by now, I haven't had the time to keep up with the super-huge pink elephant sitting in the middle of the virtual ASP.NET room that is MVC.  So I plugged "System.Web.Abstractions" into a Google search and the first hit I get is Microsoft's page for ASP.NET MVC Preview 2.  Ah ha.  I have done a little poking around on the MVC framework, but always get interrupted with "real" work. I do know enough that CodePlex is probably a good place to start.  So I headed back over to CodePlex's ASP.NET section and found a download for ASP.NET MVC CodePlex Preview 4, which I figured would suffice, since 4 > 2.  Upon clicking the link for the application download and agreeing to the license, I watched Firefox download an .msi file.  Awesome!  An MSI!  Someone had the brilliant idea of creating a deployment project to simplify the integration for me, the lowly tool user!  I happily ran the MSI and watched the install, then switched back to my VS2008 IDE with the sample project loaded and rebuilt.  

Could not load file or assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

What the hell?  Shouldn't the MSI have taken care of all of this?  Maybe I have the wrong MSI?  Wait, it didn't even ask me where to install itself.  I find the install folder in Program Files\Microsoft ASP.NET\ASP.NET MVC CodePlex Preview 4\Assemblies, and there's the elusive System.Web.Abstractions.dll.  I switch to view my GAC, assuming I'd find the files registered there.  Nope.  OK, then, I'll do it the old fashioned way.  I gacutil the three "System" DLL's, and they don't give me any "strong naming" issues and appear to register fine.  Except, I notice that the version on the System.Web.Abstractions assembly is "0.0.0.0."  Hmm, that's odd.  Must be a weird refresh thing.  I switch back to my IDE and rebuild.

Could not load file or assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Son of a bitch!

Now, I know this isn't really a big deal, but it really burns my ass that these uber-developers can't take a few minutes and 1) let me know that there are prerequisites and 2) make an MSI file that actually does something.  This issue keeps coming up for me with the various plugins and toolkits I "install."  In a deadline-driven developing world, I do as much as I can to keep up with emerging patterns and practices.  But when I run into roadblocks that could be eradicated with some simple forethought by the developing team, it stifles my ability (and my desire) to use this stuff.  I understand that CodePlex is generally for open-source, bleeding edge code that might eventually get included in the framework, and hence isn't "polished."  But when did developers forget that their audience is probably going to like them a lot more if they make their stuff easy to integrate?

After complaining more to a friend, he made me feel really stupid by pointing out that I just needed to install .Net 3.5 SP1.  After this install, I was able to build everything just fine.  Of course, I haven't had the time to actually do anything with it.  So, lesson learned: When downloading and installing stuff from CodePlex, make sure the framework is the latest and greatest.  

We are developers.  What kind of developers we are depends on who you are.  If you want us to develop your business by selling stuff or getting folks to give you money, that's the wrong kind of development.  If you are a prospective employer that is about to offer us hundreds of thousands of dollars to write really interesting projects with bleeding edge technology, than we are two things:

1. Professional Information Technology Application Developers, or PITADevelopers.  Welcome to our website!  Please contact us immediately!
2. Ready for our first paycheck.  Oh, and don't read anything after this sentence.

If that is not who you are, more clarification is needed.  Pretend you are sixteen and are in your sophomore English class.  An attractive personage (gender neutral) passes you a note that says the following:

Dear <your name>,

I think you're pretty cool.  I would like to know more about you.  Are you a/n (circle one):

1. Application Developer
2. Chicken Farmer
3. Friend or family member of this site's owner(s)
4. Psychological Profiler
5. Enterprise Architect
6. Search Spider
7. Other Technology Blogger
8. Rock Star
9. IT Contractor
10. "CSI: Miami" Fan
11. Skimmer of Tech/Dev Sites for Gray Boxes with Text in Courier New
12. IBM Employee
13. Empress
14. Extrovert
15. Someone with No Sense of Humor/One Who Takes Things Very Seriously

Please return this note to me.

XOXOXO

<Name of Attractive Personage>

To further this scenario, I will be playing the role of "Attractive Personage." 

If you circled Item 2, may we acquire some chickens?
If you circled Item 3 you probably should just stop reading now.  Your eyes may not be able to handle the amount of rolling required to continue.
If you circled Item 4 you are awesome!
If you circled Item 6 then <insert sql injection attack here>.
If you circled Item 9 go work on your resume.
If you circled Item 13, we are your long-lost children.
If you circled Item 8, 10, or 15, you are in the wrong place.
If you circled Item 5, we may actually be mortal enemies, or I want your job.

All others, welcome to the Pain-In-the-Ass Developers' website.

Now, I certainly don't want to give anyone the idea that we're bad developers.  I think we're pretty good at our jobs, which mainly consist of programming (and analyzing and designing and all that stuff) various systems with Microsoft technologies.  But we have a long history of working with Perl, PHP, and other programming languages and tools outside the Microsoft ecosystem. And we pay a lot of attention to technology blogs on the web, as well as what's happening with technology at our vastly different employers and in the general technology universe.  We're certainly not extroverted, but we're thoughtful people, and have decided to share our views on this website. 

So exactly what makes us "pains in the ass?"  Exactly what I said above.  Instead of blindly munching at the technology trough, we have sufficient experience to have evolved into people that ask a lot of questions, many of which aren't always welcome.  Personally, I have seen enough unscrupulous stuff in the application development milieu to make me want to add my voice to the mix.  This site will be my place to be a pain in the ass; to ask questions and pick unwanted arguments.  But I also intend to describe my views on coding these days, which will definitely include examples of anything cool or new that I pick up (which will be in nice boxes with Courier New font, for those that circled Item 11). 

You've got it.  You've found another coding blog.  Except this one is the awesomest one ever.