Technique vs. Technology
Over the past few years or so I’ve noticed a phenomenon that I’m calling Technique vs. Technology.When developing software solutions for computers there is always a number of ways of doing something but usually there is a much smaller set of recommended patterns that should be used. However, there are a large number of developers that don’t follow these patterns and produce solutions that have inherent problems. The reason for this is either ignorance or cost cutting, maybe both. Either way it is the end-user or customer that suffers and gives software development a bad name. So what’s the answer? The obvious reply to this is to invest in educating the developer community and to produce software tools to help developers avoid common pitfalls. Yes, to my mind this is the correct way and with the recent surge of concepts like Software Factories it would seem that many others share that opinion too. But the software/hardware industry have another angle, lets use technology to compensate for poor technique and for backwards compatibility. However, lazy (or ignorant – is there a difference?) developers can rely on these features and will never learn or comprehend why they should learn the proper technique. But then again, why should they? So I’ve waxed lyrical for long enough now, how about some examples?
Stored Procedures vs. embedded SQL
Back in the day Microsoft provided stored procedures for SQL Server with one of the benefits being that the plans are cached and reused. The problem was that when Microsoft released ADO a huge number of developers, using SQL Server, ignored stored procedures and simply issued statements directly to the server. Although ADO should be praised for its easy of use and flexibility it allowed lazy developers to produce grossly inefficient code. Consequently Microsoft spent the next few years defending ADO and repeatedly telling developers to use stored procedures for performance code. Eventually, although I’m sure there’s and official reason for this, they caved and provided statement caching which, IMO, panders to the lazy developer…although I concede there are some advantages to this. This is my first example of technology compensating for the lazy developer but really does it matter?
CSS vs. Table slicing
Web page design has gone through somewhat of a rocky few years, caused mainly by inconsistencies in browser implementation, producing two basic techniques for page layout; Cascading Style Sheets (CSS) and Table (image) slicing. CSS is the recommended pattern with lots of good points ranging from structure/layout separation, accessibility (see PDA later), downloads efficiencies, etc, etc. However, early browsers (and indeed inconsistencies with modern browsers) prevented the use of CSS. To get around this the table tag set was used to create layouts by slicing images into small chunks that could be placed within equally sliced up tables. However, there are a number of problems with this approach, basically the opposite of what’s good about CSS but for me the important problem is the accessibility. The most obvious of these problems is scaling the text within a table. In the majority of case this simply breaks the page, with text disappearing or the image slicing going horribly wrong and the original dimensions change. But wait, the browsers technology has a trick up its sleeve, zooming. The browser simply zooms the whole page rather than altering any specific Html element/attribute. So I can use tables safe in knowledge that it works on almost every browser and the user will be able to zoom the page…providing they download a nice new browser. Ok it still doesn’t solve all the problems of table slicing but it certainly becomes a strong argument especially when CSS can be troublesome to get right on all the browsers.
CSS vs. PDAs
Viewing Html on a standard 15″ screen has long since been superseded with all sorts of odd shaped viewing devices. Monitors now come in all sorts of sizes and resolutions, but the really odd sizes are reserved for the smaller screens of handheld devices such as mobile phones or Personal Digital Assistants (PDA). These screens cannot, sensibly, view a screen designed for 800×600+. Step in CSS, with device specific stylesheets you can create a nice layout for the smaller screen whereas those nasty-old table sliced sites look terrible. Well back to the real world. PDA browsers have long since given up waiting for CSS and have taken it upon themselves to use their technology to break up the tables and provide a decent view of the table sliced page. Whereas, many of the browsers don’t understand a hand-held media type and the CSS site looks terrible. So again, it’s all too easy to say, why bother?
One of the great aims for software development is that the developers should focus on the logical problem rather than spending their time solving issues with their chosen implementation language. One such area is optimisations. True they can make a big difference but if the developer types if MyString == “” or if MyString.length==0 then this sort of optimisation should really be caught by the underlying compiler. Another classic in the world of .net is the StringBuilder. If I use FxCop it will tell me that I should be using a StringBuilder for string concatentation within a loop. So rather than tell me that, why doesn’t the string concat’ do that behind the scenes? If I really don’t want to use a StringBuilder class I should be able to create a SimpleString type or something! In theory I shouldn’t have to concern myself with such optimisations.
So here is the real question, why bother spending the time using the “correct” techniques when the the majority of people don’t and therefore the technology ends up compensating for them? Granted they don’t compensate for everything, but will it just be a matter of time before they do?