PITADEV
Curiosity killed the developer's project.

Stack Overflow Dreams

Thursday, 14 May 2009 11:25 by aj

I, like thousands of other developers, have fallen in love with Stack Overflow.  I still use Google for the random programming questions that my teammates and I come across during the work day, but I am always stoked when an SO link comes up on my searches.  I generally check the site periodically throughout the day, although I don’t have time to troll it (like several other users seem to) and haven’t quite committed to setting up an RSS feed for it.  It is a tremendous resource, and though I was initially skeptical about its completely user-driven format, I’ve come to realize that that is exactly what makes it such an effective site.

For some odd reason, I’ve had particularly vivid dreams lately (no, it’s not as a result of Chantix, although it should be).  The other night I dreamt that I was sitting in my chair in our living room with my laptop on my lap, as I do most evenings after work.  I think we were watching the Twins bullpen throw another game, and my daughters were in their various states of chaos.  All in all, a very normal evening, except I was dreaming it.  Anyway, in this dream, I was in the midst of one of my frequent evening scrolls through the Unanswered question list on Stack Overflow, and noticed that my reputation had suddenly increased by 50 points.  I went to my user-profile page, and it had increased again, along with two new silver badges.  I clicked on the logo to go back to the SO homepage, and my reputation had increased by thousands, with gold badges and silver badges and accolades galore.  I was euphoric! 

Shamelessly Paint.Netted from Skeet's rep

It was such a realistic dream that I actually checked my reputation right away the next morning, only to see the sad reality  that is my true reputation.

Some day, 500!

This got me kind of mad.  I mean, what do I care what a bunch of other geek/dork/nerds think of my geek/dork/nerd abilities?  Just because I don’t hang on every single (often unintelligible) question that is posted shouldn’t make me less important or intelligent than the Stack Overflow Pantheon.  I mean, seriously, do these guys even have real jobs?  Do their bosses know that they’re spending hours of precious coding time scanning for reputation fodder?

Being a ruminant son of a bitch, I reflected on this for a while, and realized that I do care about my Stack Overflow reputation, and that’s OK, because beside being the best place on the web for software developing questions, Stack Overflow has become a center of excellence.  It is the premier community of software engineers on the internet, and having a good reputation among your peers is always a good thing.

Lately I’ve been posting more answers because I’ve decided that, good or bad, answers always help everyone.  Even if they’re bad or incorrect, they are a learning experience for both me and everyone else that sees how the community reacts to them.  It’s like a class that you really want to learn from; good students understand that in order to learn, they need to pay attention and put themselves out there, both by asking and answering questions.  And the brilliance of the site’s underlying mechanisms is that you are rewarded for putting yourself out there.  Every now and then I’ll hit the site and notice that my reputation has been bumped up by ten points because someone up-voted something I posted months ago.  That’s really frickin’ cool, if you ask me.

So, I say kudos to Spolsky and Atwood for designing a site that has become such a powerful community.  And even if my reputation sucks, I’ll still be reading, asking, answering, and ultimately, learning.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:  
Categories:   Around the Web
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Adventures in NHibernate with ISeries for DB2

Tuesday, 31 March 2009 20:10 by aj

It finally occurred to me recently that there's got to be a better way to write data access layers.  Though it's done wonders for my words per minute, it just seems horifically inefficient to have to manually set up types to encapsulate query results.  And worse than that are the magic words that are necessary to define parameters for stored procedures.  This stuff drives me nuts.  There is no reason that I should have to hard-code names and types of parameters, not to mention the general evilness of constants in general.  Sure, we all use them from time to time, but our database tables shift like Leopold Bloom's bowels after his burnt kidney breakfast, and these damn parameters have caused at least 50% of the 83,467 hours we spend on maintenance every year.

I reflected (punny!) on this madness as I inserted a snippet for a DB2 connection, command, and DataReader for the 187th time this month.  I stopped, counted to ten, and finally started researching Object Relational Mappers.  As I read through several opinions on the topics, including a novelette, I found a Stack Overflow post that I ended up spending a lot of time reading, since the answers were quite thoughtful and well-documented.  The original question's bottom line is that we don't really need entities and ORMs; we can just use stored procedure instead.  The person who asked the question did a good job presenting his point, and eloquently rebutted the wealth of responses, but I just kept thinking about the fact that at some point you still have to set up the damn DbCommand object that calls the stored procedure.  So, all apologies to the questioner, I headed over to the NHibernate website and started learning.

One of the caveats in my situation (I know we all have caveats) is that we have three enterprise databases systems: Oracle 10g, SQL Server 2005, and DB2 (ISeries AS400).  Of course, part of the obvious beauty of an ORM is that you should be able to switch between these without a ton of work.  No big deal, then.  Except that the application that I specifically wanted to attempt to use NHibernate with was for ISeries DB2.  Of the three, DB2 was the only database I'd never worked with before I started at my current position, and since it's kind of the pariah of the relational database world, I was pleasantly surprised to find that, allegedly, NHibernate supports it.  

After downloading everything I set about finding a good tutorial, which I only found on the NHibernate site via Google.  As a matter of fact, though I'm sure I'll find it to be a good reference when I get a little more seasoned, the NHibernate API Reference is quite dense, and I've found it difficult to navigate and not very intuitively laid out.  I did find several tutorials/examples, a few of which are:

  • NHibernate Best Practices with ASP.NET (Billy McCafferty) - Overall, I think this will be very, very useful for me down the road.  Specifically, the project I'm working on won't have a UI layer.  And I'll admit, this article was really long and I didn't have time to read it all. 
  • NHibernate By Example (Dragos Nuta, I think.  He at least wrote the documentation.) - I've used this as a reference several times already.  It's a very simple, straightforward DAL that shows basic mappings and criteria queries.
  • NHibernate FAQ (Gabriel Schenker) - Several blog posts in a series that starts with setting up your system for NHibernating and progresses onward through several scenarios.  All tutorials strictly adhere to TDD.

Partly because I stumbled upon it first by some magic of Google search strings, and partly because I've been wanting to give NUnit a spin (he doesn't advocate any particular testing framework, just uses NUnit for the tutorial), I started working with Schenker's FAQ/Tutorial, and have stuck with it thus far.  I find his approach to structuring the domain and repository classes quite easy to follow and I like the way he organizes his solution.  Sure, I'm translating everything from C# to VB, but that would have been the case with any tutorial found, because VB coders are more scarce by the second, and code examples using VB are practically extinct.

Truth be told, I started this post about a month ago, and various extracurricular activities (namely, my kids) have kept me from finishing it.  But I intend to follow through with more posts as I code and learn.  So if anyone is out there trying to use NHibernate with DB2, I'm hoping I'll have more information for us all to discuss as my project evolves. 

 

Currently rated 5.0 by 4 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:  
Categories:   DB2 | ORM
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Developer Jargon

Saturday, 14 February 2009 08:17 by aj

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.  

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

We All Laugh in the Same Language

Wednesday, 28 January 2009 15:09 by aj

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. 

OMG! But that DLL was written in C#!

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

IntelliSense even formats the tooltips in VB

 

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?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Code Aphorism 2 - Ruined by VB

Thursday, 11 December 2008 19:41 by aj

William Wordsworth

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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:   ,
Categories:   Aphorisms | Rants
Actions:   E-mail | del.icio.us | Permalink | Comments (2) | Comment RSSRSS comment feed

Code Aphorisms

Wednesday, 3 December 2008 21:56 by aj

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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:   , ,
Categories:   Aphorisms
Actions:   E-mail | del.icio.us | Permalink | Comments (1) | Comment RSSRSS comment feed

I like sports and beating up on kids with glasses!!!

Sunday, 30 November 2008 20:42 by kevin

And I am WAYYYY too cool for math.

Two computers, three monitors, three different browsers, one Patience.
A few hours ago, in the course of trying to figure out what was wrong with the RSS feed (the problem turned out to be this), I took a step back and noticed that my desk actually looked like this.  (only, with a bit better color balance and focus in real life)

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   Irrelevancies
Actions:   E-mail | del.icio.us | Permalink | Comments (5) | Comment RSSRSS comment feed

Hot Karl!!

Friday, 28 November 2008 08:35 by aj
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!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:  
Categories:   Around the Web
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

The Myth of OOTB (Part 1-The Rant)

Tuesday, 11 November 2008 18:42 by aj

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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:  
Categories:   Dev Theory | Rants
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

and also, consumers return to pizza after trying out the new Nauruan place down the block a couple times

Wednesday, 24 September 2008 08:21 by kevin

I tried Chrome.  It was OK.  Just didn't have that many features.  I'm kind of a nut, I suppose.  I use Opera, IE6, and Firefox, almost every day.   Opera for low-friction general browsing, IE6 for "compatibility", and Firefox for its insane plugins (there will be a post about this, soon, I guess).  I'm typing this very post in IE, because this very BlogEngine refuses to let me create new links with Opera.  (As someone who has done the "make it work in IE" thing more times that I can count, I don't think this is a problem with Opera, per se, but then, I really don't care.)

But yeah, I tried Chrome, and it was fine.  But that's the thing.  I was just trying it.  Like most people.  I wasn't looking to change my life.  Which makes the fact that Chrome has lost market share the most surprising news since my shoe fell all the way to the floor when I dropped it.  Chrome has a couple very interesting innovations -- its JavaScript VM and its process/threading model -- but the version that's out today feels a lot like the time I rode in the early prototype hybrid car my friend was working on in college in 1996.  Cool, very promising, but just not done.  I'll see if I can dig up the breathless newspaper clippings from the next day, about how 100% of the friends of the Future Car team members who had ridden around in the hybrid had gone back to driving their regular cars.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (2) | Comment RSSRSS comment feed