Seems like a rhetorical question and perhaps it is for the majority.  Yet even the obviousness can be skipped for simply the fact that we assumed too much.  A good example is the work invested in updating the Deriven FTPSecurity application for the past month.

The application works for up to Windows 2003 and possibly Windows 2008, but not Windows 2008 R2.  Therefore it wasn't going to be added to the new web site, though the download link to the previous version remains intact.   A user by the name of Greg had a request to add a new feature to the applicaton while keeping the integrity of the last version published.  The new feature was a no-brainer as far as development stood.  But testing required a machine with Windows XP, Windows 2003, or one of the premium editions of Vista or 7.  Well no test machine was available.  Instead and thankfully so, instrumentation was placed all throughout the application to locate any bugs.

 Indeed the trace logs showed the bug clear as a sunny day.  But I couldn't see it.  The code was reviewed for nearly a month with back and forth testing by Greg and his team.  Finally the bug was found by the same trace logs only that by running the code through my head did I see the problem.  Had a testing environment been set up (mind you, even the development machine could not test this application since it was not a premium edition), the answer and perhaps even more features could've been created in the same amount of time it took to get the desired feature implemented.

 Moral here is: how important are testing environments?  Even when you are absolutely certain nothing can go wrong?  In development, doubt can save time. 

So I've been approached with several questions about web development, development strategies, or some area in between where I end up talking about this demonstration I made about a year ago demonstrating some basic technical and methological concepts.  I wanted to see how quickly I could create an MVC-driven web application using nothing but HTML, ECMA/JavaScript, and AJAX calls.  Took less than a half hour to implement and came out to show a bunch of little demonstrations on how to develop web applications in addition to the MVC demonstration.  (Come to find out, not all developers are privvy to web development like their companies had expected.)  Anyway I've been meaning to drop it here for others to see/play with one day.

Basically the model, controllers, and views are all HTML that spits out JSON objects.  Two JS files are used to eval and make the AJAX object.  That's pretty much it.  The model is the names at the bottom of the index.html page when opened.  The default controller will pop up an alert when the user types something in the text box and leaves the textbox.  Click the Change Controller button to switch controllers instantly.  Then type in the text box and leave focus again.  A different message should appear.  That ends the demonstration.

 Another reason to make this example to prove a point that all of these frameworks being created around the world can be broken down to something this simple and basic -- such that entry-level developers don't get overwhelmed.  Keep it short and simple first.  Then decide which framework works for you, right?

SimpleMvc.zip (8.26 kb)

The past couple of years has exploded with new programming frameworks, better software practices, revitalized methodologies, improved hypervisor technologies, and the list goes on.  With so many options, one could be deadlocked in thought on how to engineer the next pioneering solution.  Here are some questions I ask myself in no particular order:

• What platforms will it support?
• How extensible will it be?
• How easy will it be to deploy?
• Will unit testing be necessary?
• Will acceptance testing be necessary?
• Does continuous integration come into play?
• What security measures must be implemented?
• What instrumentation is necessary to support the product?
• What new technologies could benefit this solution AND have a long shelflife of support?
• What older technologies could still benefit this solution due to its vast supporting community?
• How much time is available?
• How many resources are available?
• Oh yes! There is a need!  How does any of this apply to the need?
• Can other projects use any of the same features?
• Is it worth standardizing the solution for other projects to use?
• What is the data layer going to look like?
• Where does the PASSMADE acronym come into play?
• What kind of budget is available?
• Who is available to get some of these answers?
• Who is the project champion, if any?
• Who are the stakeholders?
• What questions did I miss?

The list goes on and on.  When I was a junior programmer, I remember just programming to program.  Some of those questions came about, but not as strong and loud as they do today.  It's as if the questions drive the solution forward rather than the answers or the unknown.  For this author, anyway.  So why do I mention this?  Well it's always been therapeutic for me to brainstorm in writing.  It's also beneficial to hear what others have to say who are going through similar tribulations.

Currently, Deriven is working on an explosion of technology use, best practice use, virtualization, ALL of that stuff .. in a new project that may or may not ever be used.  Still, it's already a two-year strong project that has opened up many challenges with the questions above.  I believe the majority of time went into answering questions than to developing -- which is a good thing, right?  One shall see.  Thankfully this project isn't about a market share or meeting a deadline.  Perhaps that lack of pressure allows development to progress.

Perhaps stress is the sole reason for so many unanswered questions and deadlocks.