Sogeti Phoenix Blogs

If you haven't read this article on InfoWorld I strongly suggest it -   The 30 skills every IT person should have .

I think my favorite is no 23 -"There is no such thing as a dumb question, so ask it ... once. Then write down the answer so that you don't have to ask it again. If you ask the same person the same question more than twice, you're an idiot (in their eyes)." 

I also like to add to this list:

31.  Learn some SQL - Even if it's the most basic of basic stuff - select *, there's no excuse for not being able to query a simple database.

32.  Don't forget your users are stupid - Seems harsh but what seems obvious to a developer will usually not be obvious to the user.  If your software makes them feel stupid then they won't want to use.  Trust me, I know.  

33.  The coolest technology might not be the best technology - Some developers are like cats - dangle a shiny object in front of them - they'll pounce on it like it's the best thing.  Just because you see everything as a nail doesn't mean the latest and greatest of something is the best hammer to use.

34.  Wear sunscreen -  We live in Phoenix, it's important to take care of your skin.

While I'm developing, I'm always making changes to code and data, and not necessarily keeping very good or accurate records in the heat of the moment about what I'm changing.  Source code is easy to resolve using modern version control tools, because I can always run a diff to see the changes that I made.  But what do I do about databases?  If I ran some ALTER statements in the database, what happens if I accidentally closed the database session and lost my changes, or if I want to go back and review what I did at the end of an iteration?  What do I do then?

Fortunately, using a trick with triggers in SQL server, I can let SQL Server keep track of the changes that I make in my database.  In my databases, the first thing that I usually create is a table for storing DDL changes to my databases and a trigger that automatically populates the table when DDL statements are executed.  By using the table and trigger, I can go back at any point and review all of the changes that were made to the database.

The table that I usually define is below:

   1: CREATE TABLE dbo.DatabaseModification (

   2:     DatabaseModificationId INT NOT NULL IDENTITY(1,1) CONSTRAINT

   3:         PKNC_DatabaseModification PRIMARY KEY NONCLUSTERED WITH

   4:         FILLFACTOR = 90 ON "default",

   5:     EventType NVARCHAR(256) NOT NULL,

   6:     PostTime DATETIME NOT NULL,

   7:     Spid INT NOT NULL,

   8:     ServerName NVARCHAR(256) NOT NULL,

   9:     LoginName NVARCHAR(256) NOT NULL,

  10:     UserName NVARCHAR(256) NOT NULL,

  11:     DatabaseName NVARCHAR(256) NOT NULL,

  12:     SchemaName NVARCHAR(256) NULL,

  13:     ObjectName NVARCHAR(256) NULL,

  14:     ObjectType NVARCHAR(256) NULL,

  15:     TSqlCommand NVARCHAR(MAX) NOT NULL,

  16:     Note NVARCHAR(MAX) NOT NULL DEFAULT N''

  17: ) ON "default";

Most of these fields are populated automatically from information gathered by the trigger.  The Note field was added by me.  This field allows me to annotate the changes in the database while I'm reviewing the database changes.  More and more often, I find that I'm adding this table to my database definitions and including the table in the production databases.  On my applications, I usually also create an administrator user interface for this table because I think that it's handy for a system administrator of an application to be able to look at what changes occurred to a database if something breaks or goes wrong for no apparent reason.  The administrative UI also allows the administrator to edit the contents of the Note field.

Here's the source code for the trigger that populates this table:

   1: CREATE TRIGGER trgDatabaseModificationInsert ON DATABASE FOR

   2:     DDL_DATABASE_LEVEL_EVENTS

   3: AS

   4:     SET NOCOUNT ON;

   5:     

   6:     DECLARE @data AS XML;

   7:     SET @data = EVENTDATA();

   8:     INSERT INTO dbo._zsDatabaseModification (EventType, PostTime, 

   9:         Spid, ServerName, LoginName, UserName, DatabaseName, 

  10:         SchemaName, ObjectName, ObjectType, TSqlCommand) VALUES (

  11:         @data.value('(/EVENT_INSTANCE/EventType)[1]', 

  12:             'NVARCHAR(256)'),

  13:         @data.value('(/EVENT_INSTANCE/PostTime)[1]', 'DATETIME'),

  14:         @data.value('(/EVENT_INSTANCE/SPID)[1]', 'INT'),

  15:         @data.value('(/EVENT_INSTANCE/ServerName)[1]', 

  16:             'NVARCHAR(256)'),

  17:         @data.value('(/EVENT_INSTANCE/LoginName)[1]', 

  18:             'NVARCHAR(256)'),

  19:         @data.value('(/EVENT_INSTANCE/UserName)[1]', 

  20:             'NVARCHAR(256)'),

  21:         @data.value('(/EVENT_INSTANCE/DatabaseName)[1]', 

  22:             'NVARCHAR(256)'),

  23:         @data.value('(/EVENT_INSTANCE/SchemaName)[1]', 

  24:             'NVARCHAR(256)'),

  25:         @data.value('(/EVENT_INSTANCE/ObjectName)[1]', 

  26:             'NVARCHAR(256)'),

  27:         @data.value('(/EVENT_INSTANCE/ObjectType)[1]', 

  28:             'NVARCHAR(256)'),

  29:         @data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 

  30:             'NVARCHAR(MAX)'));

  31:     

  32:     SET NOCOUNT OFF;

  33: GO

By creating this trigger for DDL_DATABASE_LEVEL_EVENTS, any DDL statements that would modify the database by creating, altering, or deleting database objects will get logged in the DatabaseModification table.

I've been developing software now for nearly 15 years, and I often repeat the same mistake on every project which leads me down a path to eventual doom and starting over.  This is not just my mistake, I see it happen over and over again from very good developers.  What is that mistake?

My mistake is that there are two pieces to any software development effort.  The first piece is the application.  The application is the piece that implements the features that the end-user or customer wants in the application.  The second piece is the technology.  The technology is what the application uses to implement the features.  My mistake is that I often put too much emphasis on the technology behind the solution instead of on the solution itself.

Non-developers, end-users, and other customer-type people are usually non-technical.  They don't share the same perspective for progress as I do.  I may work for a month and look back and what I have done and be proud of the progress that I have made over that month.  I might have defined and implemented 10 components that all talk to each other using contracts defined by interfaces, and I can run my NUnit tests and show that they can calculate 2 + 2 and tell me in under 1 millisecond that the answer is 4.  I can even run NUnit for my customer and let them see the green bar and share in my rejoicing.  The only problem is that the customer doesn't share in that perspective because they've seen no progress.

At the end of an iteration, what will I have to demonstrate and show?  If the customer's looking for a report with summary data and a nice chart, will I have that for them?  No.  I'll have NUnit with a green bar.

It's this perspective that often leads to friction between developer and client, and is often the first and largest failure that I see software developers make.  It's a fault of ours because we live in the world of technology and there's constant pressure for us to know the latest acronyms such as WF, WCF, AJAX, WPF, Silverlight, HTML, XHTML, and more.  As soon as someone gives us a problem, we start breaking it down by the technologies that will provide us with the best solution.  And this is where we fail.

We think too much about the technologies, while our clients think too much about the final solution.  Does it matter that the solution was a hacked up nightmare?  It might for us, but if it gives the client their summary data and a nice chart, and it doesn't make them take a coffee break and go to lunch while they wait for their report to appear, then it really doesn't matter what technology solved the problem.  It bothers me if the code is sloppy, or if the implementation is not what I wanted to deliver, but my job is to deliver a solution that makes the customer feel like they got their money's worth.  It's not to develop the technology and not deliver them something that they can use.

So when starting a new software project, or trying to fix a broken one, start with the user interface.  Give the customers something tangible that they can touch, manipulate, and play with.  Ultimately, you'll be that much further to delivering them what they want and need than if you through a bunch of technology at the solution and never provided the customer with what they wanted in the first place.

Tim Heuer, of Microsoft fame, commented on an earlier post of mine this morning and made me think of a lot of things that he probably didn't mean to get me thinking about, but I did regardless.  So here are the results of my thinking.

So when is it ok to build another wheel?  What I mean by that question is when should one rebuild something, versus using something that someone else has already written?  Or to take this another step further, should you spend time building something that someone else has built just for the heck of it, when the original work would have suited your needs?

Usually, I try to take the path of reusing other's work, because ultimately if I am able to do so, it helps me to get closer to my goal.  My main goal usually both on my personal hobby projects and my professional work projects it to build applications that serve a purpose.  My applications are usually built on technology.  The question that I always run into is should I spend a significant amount of time building technology, or should I focus on those things that will help me to actually deliver my application?  The answer that I usually try to strive for is that I want to focus on actually building the application's features, because it's the features that matter to me.  I want to spend as little time as possible focusing on technology, because it delays my ability to complete and utilize a feature, and my main goal is to deliver applications, not invent technology.

So, when it comes down to implementing a feature, if there's something out there that is usable and will help me to achieve my goal, should I use it or reinvent the wheel?  The answer is that I should probably try to use the existing technology so that I can focus on the application.

For example, I came across the SlideShare website back in January and I instantly fell in love with it.  SlideShare is one of the coolest websites on the Internet in my opinion and provides an absolutely fantastic solution to the web community for sharing information.  SlideShare lets you upload your PowerPoint presentations.  Once uploaded, SlideShare will convert your PowerPoint presentations into a Flash application, and you can view your presentation online or embed it in a web page or blog.  Here's an example:

| View | Upload your own

This is a fantastic service that SlideShare provides.  However, as a Microsoft developer and aspiring Silverlight developer, it would be super cool if I could put this same functionality into Silverlight and do something such as combine the presentation with additional text, video, audio, etc., all managed through Silverlight, JavaScript, and HTML.

Realistically (because I have researched it), this is something that is possible if I use PowerPoint 2007 and the Open XML APIs to get to the PresentationML and DrawingML markup that make up the slides.  I could spend a lot of time building a Silverlight player and doing all of the hard work to make this presentation control reusable.  Maybe I will do this one day, but right now my primary need is that I want to embed a PowerPoint presentation into a web page, and while SlideShare may only provide me with a feature limited Flash presentation, it's still good enough for what I need at the moment, so maybe I shouldn't worry about reinventing this wheel right now when my main goal is to produce content that I can share with others on the web.

That being said, is it still ok to reinvent the wheel at times, and when is it ok?  Of course it's ok to reinvent the wheel whenever you want.  The main reason why I do it at times is to learn.  I'm a technologist as much as I'm a developer.  I like to learn how things work.  I may create my own ribbon control for my applications to make my applications look like Microsoft Office 2007.  I'm not doing it because I think that I can do it better.  I'm doing it because I want to learn how they do it and understand.  I may not build a ribbon or use it in production code, but the techniques that I gain from tinkering with the technology may help me to apply the technology in whole or in part to other solutions.

Right now on this blog, we're using BlogEngine.NET.  Because I'm documenting how to use the Blogger and MetaWeblog APIs in my earlier posts, does that mean that I'm looking to replace BlogEngine.NET on this website?  No.  I may someday write my own blogging engine, but most importantly by understanding how a tool such as Windows Live Writer or Microsoft Office Word can publish content to a blog, I may find another use for these tools such as being able to publish up to a custom website that I build.  I'd much rather be able to tell my end-users that they can create their content in Microsoft Office Word, which they're usually comfortable working with.  This serves two purposes.  First, my clients can work in a comfortable place such as Word that they know and have skills with.  Second, if my end-users can use Word for content publishing, then I don't have to spend a lot of time building a web-based editing interface (at least right away).  Instead, I can focus my time working on implementing the value generating part of the project, which is the website front-end that content consumers and my client's customers will be using.

In summary, I don't think that it's always right or proper to reinvent the wheel when acceptable options present themselves.  But I'm always a fan of tinkering when it comes to learning and understanding how technology works and learning new ways to apply the technology to your job.  After all, I'm not a fan of not sharing techniques of software development.  There shouldn't be any smoke and mirrors or "magic" behind software development.  The only magic should be that we, as software developers, get to enjoy producing great software that others get to use.