What Matters Most – Part II
Friday I introduced this topic based on the difficulty of finding the best solution for a problem that can be solved with technology. The right software completed too slowly is no more valuable than the wrong software created quickly. Software needs to match the needs of the intended audience. The problem is that we are not willing to throw software away.
For example, a department needs a purchase order system for one person. You can put one together in a couple days using a tool such as MS Access. That individual demonstrates the system you developed for them to others, and they now want the same system. Again, that may be reasonable. Then they all want to share data. That is a great thing. However, even though it is possible to build systems in MS Access capable of sharing data, it is not the best tool. As soon as you get users in different networks wanting to share data, Access is definitely not your best choice.
Did you make a bad choice to provide something in Access? Depending on the company I would say the choice was a good one. However, if you work at a company who would require you extend the system to work on a broad scale using Access, then you should probably not even consider using it even for the small things. Systems grow. Others want good things. Plan to throw them away and scale them when necessary.
The other extreme is to build all systems on an enterprise scale…capable of growing infinitely. Again this is an extreme that makes no sense. The cost for design, development and testing is so large your company may have great software on the way to bankruptcy court.
Mark considers the use of new tools and technologies as another dimension of this question. He writes:
Another great article Ben,
The biggest criteria I see comes from your initial comments…”my personal experience”. Indeed your questions of scale and scope are important, but I find it’s most important to know if “you” can make the solution in question work, albeit within the project parameters. Even in the Microsoft stack, one could provide a quick and dirty solution in MS Access if it can fit, instead of a fully scalable SQL Server/IIS/.NET solution.
I am a big adopter of new technologies, but development frameworks “work” because they provide a familiar interoperability throughout the various components in their stack. I’ve been victim of trying to “fit” a project into a new or unfamiliar technology, just because someone thought we should. If one can provide a solution with what one already knows well, a good percentage of the time it is the better choice. Making the jump from .NET/JAVA to open source is riddled with pitfalls. Even when support for both .NET and JAVA is required, these don’t always “play ball” when interaction is needed beyond the basics.
Deeper levels of competency with one technology are often of much more value than some marginal benefit that might be derived by “learning” the latest whizz-bang tech. Sure, the true developer in us always wants to tinker, but I believe we must be careful to focus our tinkering (possibly even in one technology stack) so as not to forsake the main objective – provide the solution. That being said, we must not be blinded to “better” ways of doing what we do, but I tend to “evaluate” new technologies now, as time permits ;-), to see if there could be a “genuine” advantage to pursuing it further, or if it’s just another way to do the same thing – before I commit to a project using it. More often than not, I find “new tech” can be (or has already been) achieved with existing know-how (I was doing “AJAX” calls through iframes and DOM back in the ‘90’s, long before the W3C wrote the specifications for the XMLHttpRequest object in 2006).
Even if new tech is “less laborious”, greater competency is often still more efficient. Building upon an existing foundation, is normally easier than digging the ground again.
Just my thoughts, for what they are worth,
Thanks for the input Mark. You can contribute your thoughts to this conversation by leaving comments below, or sending an Email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Elemental MDX: MDX Time Series Functions: PeriodsToDate() and OpeningPeriod(), Pt. 3
Part 3: BI Architect and SSAS Maestro Bill Pearson continues a three-part overview of the MDX PeriodsToDate() and OpeningPeriod() functions, specifically designed to support the analysis of data within the context of time. In this Part, we explore the useful OpeningPeriod() time series function, and examine ways it can help us to meet pervasive business needs.
Featured White Paper(s)
Harness Your Data for Better, Faster Decision-Making
read more)
Featured Script
dba3_NorthWind_0075_Materialized_Object_Refresh_Process_Article
View it now! – Part II: Banishing view timeouts by implementing user "materialized views"… (read more)