In this article I will sound quite pessimistic. Over the 25 years I have been in the computing industry, in the UK, it has changed considerable; and from my perspective not for the better. Here are some of my observations.
1) Rise and demise of C++
In the mid-1990’s I joined a bespoke software development company (where I remain) and Object Orientation was all the rage. Customers demanded their project reap the benefits of the new paradigm, usually with no idea of what they were asking for. I fear the current equivalent are mobile apps, with no business cases to justify it. Consequently they end up paying for a self-contained edition of the ‘mobile-ised’ web site – just so they can advertise they have an App; but this is the subject of another rant.
Java developers are lazy
and, I suspect, .Net developers are no different, but it’s not their fault. I see far too much reliance on libraries to churn out generic functionality quickly. The output is completely devoid of original thought and creativity and usually places development constraints on other elements of the sytem. I blame the customers and their use of short-term contracted staff.
Quite understandably contractors are focused on delivering what is being asked of them and few ever inquire “why?”. Unless the customer fully employs a knowledgeable technical lead, there is most likely to be a complete lack of joined-up thinking, which is essential when developing anything as a team. With the product complete and the contractors released to pastures new, it is the tech lead that retains the overall understanding of the system and its composition. God-forbid he/she ever leaves the company or gets made redundant now the development is complete and their job is done. Business-critical systems need fully retained staff. Especially in these days of ‘just enough’ design, minimal documentation and risk-based testing.
Many years ago there was a tale that suggested Bjarne Stroustrup deliberately designed the C++ programming language to be over-complicated in an attempt to restore the fee rates of programmers. The interview transcript was in fact a hoax. The fact is that nowadays contractor’s are only expensive because they represent the primary cost factor (i.e. relatively to other costs like software licences and hardware). Yet at what cost to the industry? I maintain quality and engineering discipline have been sacrificed and I am not convinced the number of trained computer professionals coming out of schools and universities in the UK are going to help.
Spec it well, build it cheap
- I can fully understand the commercial drivers for out-sourcing software development to the East, but this has been demonstrated not to be as straight forward as it first appears. The cost of living differences between the West (UK) and the East (India et al) present a very attractive cost reduction but engaging this distance resource in not without issue.
Sir John “Jack” Cohen, a British retail mogul (founder of Tesco, one of UK’s top 3 retail chains), coined the phase “Stack’em high, Sell’em cheap”. The IT equivalent “Spec’it well, build it cheap” relates to the outsourcing of Software Development projects.
In order to maintain the quality of remotely developed products an increased level of design and test detail is essential. There also needs to be some hands-on intervention necessitating travel to the other side of the world. The potential financial benefits of a ‘developing world’ work force is also short-term (and short-sighted). The salaries of Indian software developers are increasing rapidly and the mobility of skilled staff is very high. It will not be long before the margin drops below the cost of supporting the development cost remotely plus the additional cost of the higher level of specification. In the meantime the size and skill of the home-grown industry diminishes. When demand returns to the UK the costs will increase for a while to enable to community to regain strength and “fresh blood” will be attracted to the industry – I hope.
2) Creative Act or Sausage-machine
Software products, even shrink-wrapped in their early development phase, are not widgets made on a production line. They are uniquely crafted and engineered works of art. Just like their equivalents in the civil engineering world, ever engine and building exhibits its unique character to those that engage with it daily. Consider your motor car; new off the sale’s forecourt it probably behaves just like those that were parked either side of it. But give it a year or two and its unique foibles will become apparent as it starts to ware in. A little later and the car will have almost acquired a personality all of its own.
I maintain, software applications, bespoke systems especially, are really no different. Except, given the engineering flexibility that ‘soft’-ware systems posses, the effect is amplified.
3) Components Integration over Bespoke Development
In my role as a technical architect I am often asked “Is’t there a COTS or FOSS product that can do that, rather than writing it from scratch?” This would be a very fair question for generic components like DataBase Management Systems, Web/App Servers and the like. But care needs to be taken when including components that require significant customisation to delivery unique functionality. To address such a challenge:
- The architect needs to conduct a market-wide trade study to identify the most appropriate component in terms of cost, complexity and effectiveness.
- The architect needs to become familiar with the philosophy behind the component to understand where its strengths and weaknesses lie and ensure it will be capable of delivering the requires.
- The developer needs to become familiar with the technique of employing (customising) the component, learning a new skill they may never use again.
- The developer needs to gain the new skill whilst trying to develop the product at the same time. Getting training should get you started, but it is going to take time away from the project and incur additional cost.
- The developer will almost certainly need to re-develop sections of the application when they realise they took the wrong approach, and may even need to start from scratch.
- The developer may have to acquire advanced skills to force the component to delivery requirements it was never intended to support and are in conflict with the very philosophy of the component’s design.
All of the points above take time and therefore cost, which combined with the cost of the component and on-going support, could exceed the perceived cost/time saving over a purpose-built component. Looking slightly into the future, what happens when the latest edition of the component comes out? or the previous product goes out of support? or the latest edition drops the killer feature? or the platform or another component compromises operation of the component? BANG!
4) Career of Diminishing Skills
The rate at which new development technologies and techniques are being introduced is staggering. Unless you dedicate a considerable portion of your personal time to self-tuition, or you have a very enlightened employer, it is virtually impossible to keep pace through-out your career. As soon as you are redirected, either though changes in home life or by following a dead/dying technology, your skill set starts to dwindle. Is this really an attractive proposition for new-comers to the industry? So, what do you do once you find yourself out of step with technology? Struggle-on, go into management, go contracting with the few skills you have left or re-train at your own cost? If you figure this one out please let me know because I do not have the answer.
5) The Race to the Bottom
When I am not supporting Clients with requirements analysis, solution design or providing other forms of technical consultancy, I am supporting the sales team with the production of proposals. This involves interpreting requirements and devising a candidate architecture from which we can derive a schedule, estimate the effort required and identify technical and programme risks. All these activities are conducted in an attempt to identify the estimated Cost but it is during the bid review when the Price is considered. There is a moot point over the relationship between Cost and Price; see the section below.
However, I foresee the downfall of the industry as the customer continually undervalues professional Software Engineering.
The Suit Analogy
There is a close correlation between the course the Software industry is taking and the way suit tailoring as gone over the past century.
100 years ago suits were clothing for the few, wealthy and privileged. Suits were made to measure and called on the highly-trained skills of the tailor’s art. After the 2nd World War, and the introduction of mass production, suits were made cheaper and sold “off the peg”. The trade-off was that suite were cut in a limited range of sizes at 2-inch intervals.
Eventually, bespoke software development in the UK will be reduced in value to the equivalent of an ASDA suit; bad cuts, cheap material and unlikely to last a year’s ware. You can still get a suit made to measure (if you have the money), but there is a third option.
On the high-street there are stores that offer suits with excellent quality of material but from a limited range and still off the peg. Their suits are cut to a far greater range of sizes and sold by an assistant who will measure your particulars precisely. Add to this a customising (tailoring) service to alert the suit to meet your specific shape and you have a quality offering; but such a service does not come cheap.
Price vs Cost
I often have the discussion regarding the relationship between the Cost and Price. I accept, ideally, the Price should at least cover the Cost in order to make a profit. However, if I understand the economics and the law of supply and demand in a finite market, the Price is a function of the value of the product to the customer (how much they are willing to pay). The desire for a supplier to enter a particular market can be a downward driver on Price. However, neither of these factors impact on the scope of work, the effort required and therefore not the Cost. The issue comes when the “effort to complete” the projects is reduced to meet the reduced the “price to win”.
The real irony is that, by all accounts, Engineer’s tend to be under rather than over estimate the development effort required!
This approach is an easy sell for sales staff faced with the demands from customer’s for the very best price. Stronger sale’s staff understand the businesses (both customer and supplier) and offer a proposal with a price based on a superior product than the competition and presents the customer with an argument convincing the customer of the value. But all to often this seems to be far too difficult. It’s far easier to simply undercut the competition and leave the development staff to “pick up the difference”; a euphemism for getting the technical staff to give up their personal time for the good of the project. The persistent expectation for unscheduled over-time is seldom paid for and could be considered tantamount to slavery!
Ultimately this model will fail both suppliers and the customer. Constantly under-costing a job demoralises the technical staff and skews the marketplace. Companies continually making a loss on projects will go out of business. A severely reduced marketplace strengthens the remaining suppliers to a point when they start to demand better (and eventually excessive) prices.