Requirements Understanding

All posts tagged Requirements Understanding

What’s Wrong with Hiring Cheap?

Posted by tropicaltheartist on February 26, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , . 1 Comment

kerry-rawlinson-TNl4aR3kidM-unsplash

Abstract: Hiring the cheapest candidate looks like sound business management, at face value, but cheaper employees can be problematic and companies may be screening out the very top talent they actually need to succeed in a highly competitive environment.  The ultimate, true, hidden cost of refusing to entertain the idea of paying fairly, to attract top talent, may be catastrophic for the viability of the company, in the long term.  The widely reported skills shortage has its roots in low pay.  Much of the best talent simply leaves the industry for good, seeking better pay elsewhere, or better quality of life.

With an exclusively financial focus, it would seem to be the case that if you can fill a certain job specification for much less money, it is a benefit to the business, but is it really?  Do people that offer low salaries really understand the consequences of their actions on the viability and competitiveness of their company?  Is a candidate that works for half the money really as good as the one that wants a higher salary and is the difference significant, if there is one?

Silicon Valley employers will tell you that penny pinching, when hiring talent, is roughly the same as guaranteeing your company won’t produce anything outstanding and will, therefore, fail to succeed in the highly competitive world of technology-based products and services.  They know that really good talent is scarce.  For every incremental dollar they pay for talent, the multiplicative effect on company value increases dramatically.

There is anecdotal evidence that, at least in the UK, pay scales for technical talent are lower now than they were ten years ago, for equivalent roles and skill sets.  Real wages have not only failed to keep pace with price rises, they’ve fallen, leading to lower material standards of living for technical talent.  Meanwhile, the complaint of a skills shortage regularly does the rounds.  What is the cause?  Why are UK-based companies so apparently unwilling to pay to attract the best technical talent?  Is low pay for technical talent an attitudinal problem, or a structural one, or both?

Many technical roles in the UK are filled through recruitment agencies.  As they predominate, the salaries they set are taken as the benchmark for all technical salaries.  In this process, the employer asks advice from the recruitment agent regarding salaries and the agent nominates a salary range on the basis of what they think they will be able to find talent for most easily.  There is pressure on recruitment agents to nominate low salaries, as they compete on price, which is ultimately tied to the salary offered (as a percentage).

Given their almost total stranglehold, as gatekeepers, on the employment market, the salaries that recruitment agents nominate, in order to keep their fees to employers low, fixes the salaries on offer to all technical talent.  Technical talent is forced into a “take it or leave it” position.  There is no possibility of negotiating a salary.  When a recruitment agent learns that a candidate requires a higher salary than that on offer via the advertised position, they simply screen them out of the recruitment process.

From the employer’s perspective, this means that they never even see the very best candidates, because the recruitment agent screens them out before their CVs are ever presented.  They remain invisible.  Employers are forced into settling for less than the best talent they need, because the salary has been established for the job specification in question.  The option of increasing the salary on offer to attract a slightly, or even dramatically, better candidate never arises, because no such candidate is ever presented to the employer.

Often times, the job specification asks for just about everything imaginable, while the salary attracts only those with, at best, a partial match to the job specification.  This attracts chancers, who are prepared to represent themselves as meeting all of the job specification requirements, while not actually having the skills and experience required.

The prevalence of chancers applying for roles has led employers to suspect all candidates of being chancers, to some degree.  This causes another problem.  When a candidate presents with broad and deep skills and experience, it can make their CV look less specific to the role advertised.  Consequently, they are assumed to be under-skilled for the role, whereas in fact the opposite may be true.  They may have such an arsenal of skills, that they make a small deal of the specific skill the role demands in their CV, even though they are more than accomplished in it.

Despite careful screening, employers frequently make offers to chancers who have bluffed their way through the process, claiming they can do more and have done more than they really have.  The problem with hiring chancers is that they are learning on the job, making costly mistakes that could have been avoided entirely, by hiring better talent.  While chancers are prepared to work for a relatively low salary, in order to remediate their work history, two chancers do not produce the same bottom line results, for the company, as a single top flight talent who asks twice the salary of each chancer.  It’s a false economy.

The moral to the story is that offering half the salary only attracts people that are half as good, if you are lucky.  They will not be able to produce the outstanding, breakthrough products and offerings that a really good candidate, who costs more, would.  If you want a higher rate of mistakes, as the candidate learns at your company’s expense, burning customer good will and competitive advantage in the process, hire inexperienced and cheap talent.

Setting low salaries for technical talent is a “red flag” signal, to candidates, that the company does not properly value the contribution of its technical people.  A company that is unwilling to move on salary, on discovering an outstanding talent beyond their nominal salary range, is kissing a valuable opportunity for outstanding performance and results goodbye.  On the rare occasions that top technical talent finds a company with a position to fill, sticking rigidly to a fixed idea of what the salary ought to be, without being open to negotiation, is going to guarantee that top talent goes elsewhere, perhaps to a competitor.

By the same token, working for too low a salary, relative to one’s skill set, sends the signal that you don’t value your skills, experience or contribution either.  This leads to abusive or difficult working relationships in both cases.

There is an ageist bias that works negatively in technical recruitment, as well.  Most recruiters, today, are drawn from the ranks of the Millennials, or those born in the decade before.  Millennials, it appears, think that nothing of significant technical merit happened before they were born, whereas in reality some monumental technical feats were accomplished, using computers that were too slow and which had not enough memory, to provide user experiences that were often superior to those provided by profligately wasteful, modern technology stacks.  I know of at least half a dozen of the finest engineers from that era, top talent, currently struggling to find a suitable role for their skills.  While their credentials are impeccable and their abilities beyond doubt, among their peers, recruiters born much later cannot understand or appreciate the value of these long work histories, it seems.  They are frequently overlooked for younger, cheaper, less capable candidates.  Employers are, again, short changed.  Talent is squandered.

About a decade ago, there was an enthusiasm for offshore development, because it was thought that much cheaper engineers could be hired to produce the same quality of result, due to differences in exchange rates and local costs of living.  While the engineers were often impeccable, the use of offshore development teams came with hidden management costs.  The most expensive part of using offshore development teams turned out to be in transferring the requirements and domain knowledge to remote developers.

Irrespective of how diligent, capable and dedicated they were, offshore developers struggled to produce the same quality of finished technical work as those that were embedded in the markets and geographies they served.  Rework was more prevalent and products mismatched to requirements were frequently produced, due to incomplete understanding of the problem domain, despite the best will in the world and sincere efforts to produce the right thing.  The enemy was simply the paucity and limited nature of the rich communication that is required to produce excellent technical things, caused by distance, language incompatibilities, differences in cultural norms and expectations, and time zone differences.

Offshore development proved to not be a route to cheaper results, but the effect on technical talent salaries was that it depressed them, because the perception arose that the same technical talent could be obtained for much less money.  Factoring in the additional costs of managing offshore development, however, this was never true, but that did not stop the chilling effect on technical salaries.  Offshore development often ended up costing more, in the end, than on shore development.

Very few of the best technical talents can afford to work cheaply, due to the cost of living where they are and their stage in life, with its attendant commitments.  Working at less than would be required to maintain a reasonable standard of living, in the overpriced real estate markets that characterise the location of most technical jobs, means that the technical talent must accept a considerably reduced standard of living, effectively subsidising their employer through their own personal sacrifices.

Having worked hard and incurred considerable expenses to become top flight technical talent, it is very unattractive to be required to accept a lesser remuneration today, than a decade previously, yet that is precisely the offer many technical employers are making to potential hires.  For this reason, employers can only fill their positions with people who are able to structure their living expenses to work for less.  This means single people, younger people and people with alternative or supplementary incomes (parental support, etc.).  That eliminates a lot of the very best people and the very valuable skills they have.  It also dooms the people that accept lesser salaries to permanently constrained lives, in which having children, for example, becomes impossible, financially.  Recreational and discretionary spending is also severely constrained.  Work becomes their whole life and drudgery.  Consequently, they become progressively more miserable, increasingly unwell and less productive.  Outstanding products will not pour forth from people working under such duress.

What many financially-oriented people, in a company, fail to recognise and acknowledge is that their company’s value derives critically from the talents they hire, especially in engineering.  Making people disaffected, financially distressed and grumpy, by underpaying technical talent, or else hiring the relatively incapable and inexperienced, puts the value of the entire company in peril.  Even the best marketers and chief executives cannot sell substandard products profitably, if produced by mediocre technical talents.

If a company hires somebody relatively cheaply, to do their hiring and firing for them, they often lack the experience and wisdom to really know what they are looking at, when the candidates for various positions they are trying to fill come in.  Their hiring decisions are apt to be sub standard.  There is also some evidence that they hire to protect their position, not to find the best possible talent for the company.  Feeling insecure about their own qualifications, they tend not to hire outstanding individuals who might eclipse them, within the organisation.  They rarely recognise exceptional talent, anyway.

In recruitment, the inexperienced hiring manager makes some characteristic mistakes.  For example, when technical people applying for a role have done a lot, in their career, it is a total misreading of their CV to assume breadth of experience means shallowness.  This perception arises when you fail to take into consideration the sheer length of their career, relative to that of a person who looks more specialised, but has only been working for a handful of years.  It is also a mistake to hire somebody that appears to be more dedicated to the narrow job specification advertised, because the limited range of their skills gives the impression that this implies depth, on their CV.  What you are actually getting is somebody with not very broad experience, not a specialist that will do superior work.

The lack of experiential breadth means the seemingly more specialised candidate will not know how to really do the job, because real working roles are rarely as narrowly and specifically defined as the written job specification suggests.  Broadly skilled candidates bring highly valuable, additional abilities to the company that the job specification writer may not even be aware the company desperately needs.  Inexperienced recruitment consultants and inexperienced people making the hiring decisions compound and exacerbate this issue, with their obsession with exact keyword matches between CVs and job specifications.  Buzzword compliance is a poor measure of ultimate candidate value.

Somebody struggling to make an entire career, specialising in just one thing, is not a better hire than somebody that has successfully accomplished many things, professionally, including the particular area of skill written up in the job specification.  The more broadly skilled candidate is the more valuable because, not only do they possess the depth necessary for the specialist role advertised, they can also readily adapt to do the thousand and one other things that a real job requires of them.  They are rarely in a position of not knowing what to do, when faced with challenges beyond the nominal job specification.

Strangely, underinvestment also has played a role in depressing technical salaries, in recent times.  While potential investors, with piles of cash, certainly exist, they are currently hoarding it, rather than investing it, for fear of the mass market not having the discretionary spending power to buy anything they might make or offer, produced by any enterprise they might invest in.  As inequality has increased, the tendency to impoverish the middle classes, which describes the economic status of the best technical talent, has also increased.  The richer the richest have become, the poorer the best technical talent has consequently become.  Potential investors are playing out a self-fulfilling prophecy, as their failure to invest guarantees that fewer people have the money to spend with any enterprise.  Enterprises, therefore, find it harder to make a good return on any investment.  As a result, good investment opportunities have become harder to find.  It’s a downward spiral.  Cash hoarders, ironically, are ensuring that the value of their hoarded treasures is more in peril of collapsing than ever before.

The perceived skills shortage has its origins in low pay.  Some of the best talents simply find better things to do with their lives, which are more remunerative or which offer a better quality of life.  As a result, they leave the industry for good.  Their skills are no longer available to potential employers.  Low pay for technical talent drives out excellent skills, leaving a vacuum in its wake and creating an artificial skills shortage.  There may be many candidates, for each advertised role, but the best skills are no longer in the market.  The overall quality of candidates is reduced, as the best and brightest simply exit the market forever.

Great talent, if you are lucky enough to find it, is worth every penny to a company and then some.  The returns on investment in outstanding people are always much more than any increments in salary required, to secure their services.  Setting salaries at too low a level screens out exceptional talent.  Those are the very people who are necessary to create extraordinary offerings.  No company can thrive, or even survive, offering unremarkable products, today.

A Rotten Way to Create Anything

Posted by tropicaltheartist on February 16, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

giuseppe-cuzzocrea-E5kBdpQ7kQw-unsplash

Abstract:  Under-estimation in technical projects is chronic and widespread.  It arises from bad beliefs and behaviours.  The consequences of under-estimation harm both projects and people.  It also causes under-delivery of promised project features.  It is wiser to choose to properly estimate and fund complex enterprise and development projects.

Yesterday, I had lunch with a dear friend and colleague, for the first time in a decade, who I have known for close to fifty years.  We’ve been good friends, man and boy, but have lived in different countries for several decades.  At one time, I worked for him, in the IT department of a tertiary educational establishment.  Throughout most of our working lives, though, we’ve experienced the world of enterprise Information Technology (IT) and of software development from the perspective of different countries and continents.  What astonished us both was the commonality of experience, in our working lives.  There are global factors that appear to arise, no matter where you practice engineering or technical management.  Perhaps they derive from human nature.

What emerged, early in our catch-up discussion, was that we had both frequently worked on projects whose estimates had been approximately one third of that which, as time would tell, were actually required.  Time and again, we both encountered budgets and timescales which should have been tripled.  With this underestimation problem being so commonplace and seemingly ubiquitous, we began to ponder on why it might be that estimates were so often risibly low and what the knock-on consequences of that perpetual error were.  It was an interesting and far-ranging discussion, drawing on our decades of experience in the industry.

The problem with ludicrously low under-estimates is that the technical and people problems you must solve, during any technical project, must be solved no matter what, or else the project delivers nothing.  There is no way to estimate and budget these problems away, by simply declaring them to be non-existent, on paper.  They happen anyway.  The remedial works you have to do mount up and press on the team and project stakeholders alike.

The issues accumulate, assert themselves and demand answers, which cost time and money.  If there is no time and money available for these unexpected, but wholly predictable and easy to anticipate issues, then other sacrifices are inevitably made.  Usually, the sacrifices involve demanding donated personal time, from those working on the project, or else the deliverables are decimated, resulting in a less than satisfactory outcome for the project’s sponsors and end users.  The opportunity costs, associated with addressing unbudgeted additional tasks, are particularly high.  While you are spending the project budget on fire-fighting or rescue missions, you aren’t using that funding to create needed functionality.

When things go wrong, during a technical project, you have to fix them.  If you don’t fix them, nothing works.  If you do fix them, you need to spend time and money that hasn’t been allocated or budgeted for.  The robbery required to fund the remedies usually takes place at the expense of the people working on the project, or on the delivered functionality.  In the case of a minimum viable solution, taking any functionality away from the deliverables runs the very real risk of causing the solution to be non-viable.

It has to be said: the main cause of under-delivery is under-budgeting, most of the time.  Peter is robbed to pay Paul and then people wonder why Peter is unhappy.

So, why do professional, educated, experienced people perpetually make these hideously silly under-estimates and why are they accepted as immutable gospel?

We both agreed that there is an over-zealous willingness to make “acceptable” promises to project stakeholders and sponsors, which is to blame for chronic under-estimation and hence under-investment in technical solutions.  At the first sign of disapproval, the estimates are reduced.  This is understandable in a hierarchical power-relationship, where the person with the more powerful position (usually the one with the money) can hurt the one making the estimates, if their pronouncements are met with disbelief; feigned or born of ignorance.  The terrible fact is that project sponsors can and do hurt people that steadfastly defend realistic project estimates.  They always want them to be lower.  They are prepared to dispense harm until the estimate they want is the estimate they get.

It is only once that these estimates sound musical to the ears of the sponsors that they become frozen in stone.  The other terrible fact is that, even if the estimator agrees to a musical-sounding, acceptable, low estimate, the practical impossibility of delivering to that estimate will also cause the estimator to be harmed by the project sponsor.  From the point of view of the estimator, you are going to be hurt, whether you low-ball the estimate and fail to deliver on it, or else stick to the realistic estimate, which your experience tells you is the true figure, but displease the sponsor with the discordant sonic nature of your projected numbers.  The duress is merely delayed, in the case of offering a derisory under-estimate.

Project sponsors, for their part, are usually mired in debt and cash flow precarity.  Their imperatives to call for low estimates are born of fear and desperation and a naive belief that software comes from thin air.  They wear their lack of insight into the technical development process as a badge of pride, citing their specialism in money matters as a justification.  It’s a form of wilful ignorance and arrogance and leads to very bad decisions, when it comes to funding technical development.  Their every decision, related to sponsoring technical development projects, is, by necessity, based on hearsay, gut feeling and guesswork.

Younger, more thrusting career ladder climbers see advantage in estimate disputes.  If they are trying to score points and win the approval of superiors, in order to get ahead, they will make extravagant promises of being able to do something for nothing.  If they have credibility, the sponsor will gravitate toward the nirvana-like lies, rather than be supportive of more rigorous, fact-based analyses.

What the young go-getter is rarely aware of are the consequences of their seemingly attractive guarantees.  They’re heedless of the terrible downstream ramifications, which in reality nobody wants.  They are also oblivious to what their promises will require them to do to innocent other people, many of whom are the very creators of the technological solution that everybody depends upon, in order to make good on their impossible pledges.  They’ll end up being hated by everyone and hating themselves.  The psychological damage related to this turn of events cannot be underestimated.

Of course, at the point of the inevitable, predictable outcomes rearing their grotesque heads, not a single person that placed pressure on the estimators to deliver a low estimate will be willing to take responsibility for them.  That particular badge of dishonour is usually placed squarely on the technical team and their commitment and competence called into question.

With this turn of events being so common, it is little wonder that my friend and I have not advised our respective teenage children to pursue careers in technology.  We wouldn’t want them to experience the trauma, as interesting and fulfilling as creating things from scratch can be.

Agreeing to under-estimates sends out a broadcast message, throughout the organisation, that technical work is not valuable or to be valued highly.  It casts the aspersion that the technical developers are lazy, good-for-nothings who perpetually sandbag and pretend the work is much more complex and difficult that it really is.  Of course, in reality, the reverse is true.  Technical developers are dedicated and diligent, working far harder than most of their non-technical colleagues, to deliver work that is far more complex and difficult than even they themselves will publicly admit to their colleagues.

One of the drearily predictable and inevitable consequences of under-estimates is that if you are replacing a number of custom-built, bespoke systems with an enterprise-wide, common platform, individual groups, who once had their perfect system, which did everything they wanted to do, the way they wanted to do it, will lose sometimes vital functionality, as it is sacrificed to meet the needs of the dwindling project budget.  The reason they cannot keep their old, bespoke systems is that the organisation cannot afford the maintenance costs on all of these peculiar, vertical solutions.  Only an enterprise-wide, horizontal suite of software makes economic sense.

However, because of under-estimation, they lose utility, when things they once had fail to materialise in the new system rolled out.  The vociferous backlash, coming from system users who are no longer able to do their jobs in quite the same way as they used to be able to, cannot be underestimated, either.  It can bring a change management programme to its knees.

The fundamental problem is that estimated development budgets seldom seem to include the research or maintenance and solution evolution costs.

Firstly, there is scant acknowledgement and recognition of the need to find out what the development team doesn’t know and to learn it, before the work can be accomplished successfully.  There seems to be a preference to pretend that everyone on the team knows everything they need to know already, at the inception of the project.  This leads to construction of the software with significant and telling gaps in the developers’ knowledge.  Obviously, that can lead to downstream issues.

A reasonably complex enterprise system, once installed and running, is rarely static.  It must be maintained, so that it continues to serve users.  Capacity must be planned, upgrades and patches must be applied at intervals and data must be scrupulously backed up, in the event of disaster recovery being necessary.  The system generally evolves, as the organisation is supports also changes.  Both maintenance and evolution have costs and corners cut, during the initial development of the system, can dramatically increase these costs, which are seldom accurately budgeted for, anyway.  System evolution and extension costs are normally regarded as operating costs, but they are really ongoing development costs.

Technical project funders imagine they can get away with cutting the funding for IT and development projects with few practical effects.  Without being mindful of the fact, often, their mental model is that the software they need will somehow appear, due to diligent programmers working harder, or donating their personal time to the cause, or else that their enterprise system will be miraculously conjured out of the ether, by some form of technical magic which they don’t fully understand.  Such a belief is, of course, utterly nonsensical.  Making anything takes time and effort.  If that effort and time is not paid for, it either won’t happen at all, it will be donated grudgingly and sparingly or else they are expecting people to do real work and create tangible value, for free.

Project stakeholders, who ask developers, already under extreme budgetary pressure, if they can add additional functionality, without additional funding and time, using the incantation that begins with the magic words; “Can you just…?” are particularly frustrating and odious distractions that raise the hackles of any development team.  If anybody asked them to do more work, spending more hours doing it, without any additional pay, funding or deadline extension, they’d be furious, yet they blithely, breezily and happily ask for additional features in the software project, as if they come from a bottomless jar of features, for nothing, in no time.

Once the project funding dwindles and the development team begins to be unfairly seen as obstructive, difficult and incompetent, their work performance is scrutinised minutely.  Their every movement, decision and choice is second-guessed, restricted and commented upon.  These judgements are made, often multiple times, by other people in the organisation, who neither understand what the developers do, nor could do it.  Micromanagement by non-technical managers is thought to be the answer to wringing more software out of less money; the unjustified implication being that the technical team is catastrophically and dysfunctionally disorganised.

Ignorance of how software must be created, for it to have lasting value and low cost of ownership, makes for a very poor project sponsor.  It leads to needless, arbitrary, artificial haste, which is self-defeating anyway.  Pared-to-the-bone staffing levels mean that quality is invariably the first casualty.  Corners cut in testing and quality assurance, the first candidates for cuts, come back to haunt system users in the form of egregious software defects that never seem to get resolved.

This kind of poor corporate behaviours sets up the developers to be permanently on the back foot, fire fighting and under constant, extreme pressure.  Sheer corporate denial of the true costs of development projects leads to corner cutting, short changing the user, making the developers feel bad and to lose pride in their work and in their achievements to date.  It is demoralising and soul-destroying, resulting in a lot of jaded, cynical, burnt out people, who have little residual loyalty to the organisation that has reduced them to this state.  You can’t help getting the sense that people’s parents did not raise them for a working life under these conditions of prolonged psychological stress and social engineering.  It’s the stuff of nightmares.  The emotional and psychological scars are long-lasting.

At the nominal end of the woefully under-funded project (for these projects have a habit of running indefinitely, as the mistakes made have to be patched up somehow, usually by a skeleton maintenance staff), reputations are trashed, pay stagnates, appreciation is never forthcoming, career trajectories are damaged and derailed, stress and depression have been induced, health is damaged and all in the name of delivering something that couldn’t have been built for the time and money available in the first place.

The way that IT and R&D projects are chronically under-funded, poorly run and mismanaged is no way to create anything of aesthetic, technical, business or artistic merit.  It’s a very poor method and model for obtaining utility and growing the value of an organisation.  There’s nothing remotely nurturing about it.

It does make you wonder why anyone with programming or technical talent would want to create anything, under these needlessly Draconian conditions, which arise solely from a fictitious belief that complex, valuable software comes very cheaply.

When Apps are Good Apps

Posted by tropicaltheartist on February 14, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

sara-kurfess-6lcT2kRPvnI-unsplash

Abstract: Apps are only good when the people that make them care to make them good. It’s not about technology choices. It’s about caring about the user and supporting them with a good user experience. If you can’t say what and who the app is for, with clarity, you’re probably working on a bad app. What matters is what the user is trying to do with your app. Users should find it easy to get their job done. Apps the users love have a better chance of succeeding.

It’s no mystery.  When desktop, web, or mobile software applications are good, it is because talented people cared enough about them to make them good.

There is no single, right technology choice that creates a good application.  It’s not even possible to choose the right development process to guarantee the application is excellent.  Neither the best technology nor the correct choice of development process is sufficient to make an application good.

Creating good software applications is all about giving a damn about the user and making sure that the technologies and processes you choose support the aim of giving the user a superior user experience, rather than fighting that goal.

If you cannot clearly articulate what and who the application is for, you’re probably creating a bad application.  If you don’t create unobtrusive, intuitive to use, elegant tools, you’re presenting users with needless complexity and confusion.  More options are not always better options.

Too many development teams get caught in endless arguments about the merits of one programming language over another, which application framework is the best choice, how to best find and remedy defects and whether or not you should have continuous integration and delivery, at the core of your release pipeline.  All of that doesn’t matter, if you don’t care about the user and what the user is trying to accomplish with your application.

Most users won’t know or care how you constructed your application, or what with.  What they care about is what it can do for them and how hard or easy it is to accomplish that.  Sometimes, developers focus on the wrong aspects of the project.  Users care only about getting the job they want to do, done, with your tools.

It alarms me how many development teams put user considerations last.  Adopters of your software, who fall in love with it, are your life blood.  Do something to the design of your offering that makes your application worthy of their enthusiasm.  Don’t leave success to chance.

The Stupidest Way to Design a Software-Rich Product

Posted by tropicaltheartist on January 27, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

cecilia-fornazieri-Yuik6-xIgoM-unsplash

Abstract:  Divorcing a product design’s key technical characteristics from its shape, feel and market appeal sets your company up to develop a product that works badly, even if it looks great.  Product development requires a broader developer skill set than straight-forward coding.  Saving pennies on product design, which will determine the fate of your company, is stupidly suicidal.

I’ve done a lot of full lifecycle product development, in my time, going from back-of-the-envelope concept, to refined minimum viable product definition, through to prototype models and onward to shipping product.  Most engineers that work for software product development companies have not.  It’s an important gap in their knowledge.  There’s much more to developing a great product than coding well.

When a company designs a new product, there is usually a lot at stake.  For one thing, the company’s entire future prospects may hinge on how successful the product is and how quickly it establishes itself in the market, after launch.  There is an entire product design discipline that goes under the banner of “New Product Introduction Processes”, which is necessary to ensure that the right product for the market is built, with the right characteristics, to make the product a runaway success.  Failing to do any one of the necessary new product introduction process steps has the potential to make the product fail in the marketplace.

A crucial part of the new product introduction process is the up-front ideation and product definition.  This is where the design tradeoffs are made.  Here, product marketeers and engineers gather to determine what product characteristics will be offered and a first cut at how those might be realised is contemplated.  Technology has limitations, but it also makes incredibly worthwhile and attractive product features easy to implement, if you choose the right technology.  Choose the wrong technology, or be forced into a compromised technology choice, for bad reasons and you may create a product that just doesn’t work in a way that is satisfactory to your customers.

Product design has to start somewhere and often, that’s in the design studio of an industrial design firm.  They will produce sexy, three-dimensional drawings and photorealistic renderings of a beautifully sculpted object, which will be the thing you ultimately ship as your product.  It can be a device (and often is), or else the visually appealing designs of some fancy web or mobile applications.  In both cases, some electronics and/or software will have to go into the design, to make it actually work, but industrial designers know little about user interaction, software and electronic components, in the main, so this tends to be an afterthought.  (N.B:  The better design agencies do have electronic design and user interaction design capabilities!)

If the industrial design agency is permitted to characterise the minimum viable product (MVP) on the basis of meeting the functional requirements in the brief, independent of any software and electronic engineering design input, a product release disaster can ensue.  A “look alike” prototype has been produced, but so far it looks good and doesn’t do anything.  Sure, tooling up for the sexy case or the fancy graphical design has long lead times, so you have to get there early, but what about the non-functional requirements of the product, which are an essential component of the product’s actual appeal to paying customers?

In stupid product design, it’s after the look-alike prototype has been designed and the MVP feature set determined by the agency that the technical staff are hired.  This is where the trouble starts.  Usually, to save costs, an outsourced development house is chosen.  The risk is seen as smaller, because the money spent on development is less than for a dedicated, in-house team.  It isn’t.  Here is what you sometimes (often) get:

Firstly, the developers will have no clue about your company, your market or what the product has to do.  They will share little of the cultural context and know almost nothing about the products that compete with yours.  In essence, they can code, but code what?

Satisfying the requirements of a user story in an MVP product backlog can be done multiple ways.  The solution can be elegant and make customers delightedly happy, or else it can be kludgy, awkward, and bass-ackward, causing endless annoyance and frustration to users.  Both solutions tick the agile development “done” box, but only one of them makes your company’s new product sell and maintains the goodwill and loyalty of the user base.  How can the remote developer tell which solution is which, with so little context and immersion into the world your company serves?

User stories require elaboration, but this becomes much harder to accomplish, if the product definition people are remote from the coders, in different time zones and with language issues to navigate.  Essentially, you are setting your product up for failure, because the high bandwidth, rich, frequent communication that needs to take place, between the developer implementing a feature in a user story and the person who wrote the story, as part of the MVP definition, is exceedingly difficult to schedule and accomplish.

Then, long after the industrial design agency has disengaged and moved onto other clients, it is discovered that the look-alike prototype is too small to put a big enough battery in it and there is no way to dissipate the heat generated by the electronics.  There will be a lot of software running in the background, you learn, so the unit will always be draining battery and running hot.  Even the sexy “home” button will have to be used much more often than anticipated and there isn’t the room to put in a switch with the rated number of switch actuations actually required.  There’s no room for a beefier switch.

Because nobody wants to redesign the sexy outer shell and scrap all the expensive tooling, at this late stage, a smaller battery is the compromise and the switch will, for certain, wear out within a few months of ownership.  Sadly, for sexiness reasons, the case is snapped together and bonded with superglue, in the factory, so there is no possibility of changing batteries in the field.  Suddenly, you have created a product with too short a battery life, which runs way too hot and which has a switch that fails within a few months that cannot be user-serviced or serviced at all, in the field.  Bravo!  Your product has gone from being a winner to being a dog last loser.

In product design, I always advocate a “work alike” prototype, before the “look alike” is made.  Why?  Well, it’s a chance to test the non-functional requirements that will be the difference between your product being viable or not.  You can test the battery life and heat dissipation.  That will tell you how big a battery you must include for the product to be saleable and successful.  You can also put in the switches, connectors and other things that the product needs to have, rated to a suitable lifetime of normal use.

For software applications, a work-alike prototype gives you the chance to run usability labs and make the software easier to use, before you freeze the wrong design in fancy, brochure-quality graphics, placing key functionality in terrible on-screen locations.

Having written some software to exercise this dog-ugly prototype and measured what’s going on, you now know how to constrain the sexy case design, so that it not only looks sexy, but it also provides a suitable enclosure for a product which actually works the way your customers need it to.  The sexy case is designed around the essential performance-determining technical components.  It doesn’t constrain them.

If you employ engineers that know about new product introduction processes, they also use the work-alike prototype to get preliminary EMC compliance and electrical safety tests done.  It complicates the new product release, but in so doing, it ensures that the product shipped will not have to be recalled, that everything works correctly, right out of the box and that the earliest adopters will not be product guinea pigs.  They can be first in line to buy the product and rely on the fact that it does what it says, in the marketing blurb.

From a software point of view, creating work-alike prototypes of the software, outside of the final shipping case design, allows early iterations around working product features.  They can be exercised, at an early stage.  You can discover that you don’t need that second front panel switch after all, or else determine that the product will be useless unless it has one.  You can also guide the look-alike prototype designers regarding human affordances, so that nobody tries to ship software with a cursor that is too small to actually touch, on the final miniature touch screen, or else places key functions in places that are inaccessible, unless you happen to be double jointed.

Product design is not a series of separated, isolated, serial operations.  It’s iterative, messy and interconnected, so different disciplines have to be prepared for resets in their progress, because a dependency discovers something unexpected, in their design work.  Product characteristics are not a gloss coat painted over a neutral technology platform.  They interact intimately.

To the customer, how the overall product works, what it is like to live with and how useful and relevant it is to their real lives is what counts most.  Putting lipstick on a pig doesn’t achieve the desired result.

It’s a form of self-inflicted, self-destructive, delusional insanity to try to shave pennies off the cost of your designers and developers, during the design of the very thing that is supposed to sustain the company.  If you cut your design effort to the bone, using the cheapest of everything, you get a crippled, vandalised product.  Given how much depends on the success of the product, it’s plain stupidity to think you can get away with throwing vital aspects of your key product’s design over various anonymous walls and hope for a coherent result.  It’s like shooting yourself in the foot, before you even launch.

Above all, use seasoned research and development engineers, with new product introduction skills.  Just being able to code isn’t enough.

What Don’t We Know?

Posted by tropicaltheartist on January 27, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

dex-ezekiel-fg8tdcxrkrA-unsplash

Abstract:  Development managers often conceal the fact that not everything the team needs to know actually is known (or can be known), at the beginning of a development project.  This leads to poorly designed products and missed deadlines.  Stakeholders are let down and feel deceived.  Developers are punished for other people’s deceptions.  It’s better to state the unknowns, honestly, even if you lose face, because honesty and transparency are paramount and lead to better software development outcomes.

One of the more insidious problems, in development, is intellectual dishonesty.  An architect, or development manager (or team) will be selected to develop some software product, or other, and there will be a lot of the company’s success riding on the outcome of the project.  Everybody knows it’s important and that nobody must be seen to be “difficult” or impeding the project, for no good reason.  The temptation to simply present the development exercise as one of simple, routine execution, based on well-known certainties and a full and lucid understanding of the requirements is immense.  In other words, there is a great deal of expectation that the technical team pronounce the project as “easy” and to offer iron-clad guarantees on cost, feature set, quality and delivery dates.  These guarantees, if given so robustly at the beginning of the project, are almost certainly fictitious lies.

The problem is that if the project is truly worth doing, it will carry some unknowns and risks.  There is little point developing something that already exists, which can be bought, so for something new to be made, there will be things that the development team will have to research, experiment with and discover; maybe a lot of things.  An intellectually honest manager, or software architect, would acknowledge the scope of the unknowns, imagine the best and worst case scenarios and detail them.  Unfortunately, that’s often not what happens.

We all have different experiences and expertise.  Not a single one of us shares the same track record as our colleagues.  We’ve all come from different backgrounds, product developments and technology stacks.  We also all have different interests, as people.  Some care about the details, others are clear on the big picture business drivers.  Nobody can know it all, but the temptation is to pretend you do.  That is pure posturing and it’s ridiculous, because it puts the software project that the company’s fortunes depend on, in peril.  It comes from a deep seated insecurity and a fear of being let go, if you don’t appear to have everything in hand, under control and fully understood, all the time.

Key project stakeholders, also aware of how important the project is to the fortunes of the company, will exert extreme pressure on the technical staff to come up with dates, costs, scope and quality promises they can bank on.  That’s what they need.  Their belief that a technical person can actually give them those guarantees, based on an insufficiency of information, is naive at best and foolhardy at worst.  In some cases, the non-technical stakeholders are merely Teflon coating themselves, in the event that the project doesn’t meet its goals, which given the behaviour of the key stakeholders, it almost certainly won’t.  At that unhappy moment, they’ll be able to point to the technical guarantor of project outcomes and throw them under the proverbial bus.

The technical person often succumbs to the political pressure to pretend to know what all the answers are and what product features are required, or about the problem domain in detail, when they really don’t.  They’re trying to save face and to please the other stakeholders, when the truth is that they may not fully understand the customer requirements, the industry that the product sells into, the competitive landscape, the technology choices for this particular project, the abilities and limitations of their development team members, the peculiarities of the tools they will be permitted to work with and a thousand other variables that can drastically impact cost, delivery date, feature set and quality, no matter how agile the development method employed.

The thing about unknowns is that they inevitably assert themselves, during development.  If the technical staff member has been too keen to nail his reputation to the mast by making unbreakable, non-negotiable promises to the other stakeholders, then as soon as one of those unknowns goes in an inconvenient direction, for him, there is no way to rescue the product launch, the project budget, the reputation of his development team or the business from the disappointments that will arise.  A bloody and brutal death march will result, with developers whipped and flogged, almost literally, to “make up for lost time”, when the thing they were attempting was always going to take longer and cost more than the initial guesstimate promises made.

A good and seasoned development manager exposes what isn’t known, by the team, at the start of the development project and brings any new unknowns to the stakeholders, as they proceed.  They explain to other stakeholders not only what isn’t known, but what cannot be known and how long it will take (and what it will cost) to do the learning and research required to eliminate the unknowns.  This extra time and money needs to be baked into the project schedule and budget at the beginning.  In order to identify what isn’t known, though, some confession will need to take place.

The team members and management will need to be open and up front about what they do not know, even if that exposes a gap in their expertise or experience.  As I said before, not everybody can know everything and nobody knows it all, so stakeholders need to be realistic in acknowledging the team they have, while talented, always have some learning and research to do.  That’s just in the nature of making something brand new, which didn’t exist before.  You literally cannot hire a team of people that know all they need to know to do the job without stopping to learn new things.  If you can, it’s a warning sign that the product you are about to create has no unique selling point.  It has been done before.

Some company cultures posture in a stupid, macho way, belittling anybody that confesses to a need to learn something or to a gap in their knowledge or experience, but that’s a very stupid posture to take, given that it applies to all developers and their managers.  The reality is that people always need to climb learning curves, dig deeper into what they’re being asked to produce and learn about this particular market and customer base.  There really is no such thing as pure development.  It’s a myth.  Every development exercise carries some burden of necessary research.

Agile, as a development method, does not make the research part explicit.  Perhaps that’s why stakeholders think that any team which cannot execute on a product backlog and task backlog, mechanically and interchangeably, is a sign that the team members are incompetents.   If we don’t call out the need for individuals to learn as they develop, then the expectation is set that the job market is full of perfectly trained, fully formed developers that intuitively know everything about your product, customers, competitive landscape and market.  How could that possibly be, unless every developer in the world developed exactly the same products, for the same people, using the same technologies and tools?

These same stakeholders, who will deny funds for developer training, have an expectation that all other firms, in the world, pay generously for people to be trained, or else that the individual developer has so much spare cash and time, that they spend it all on personal training courses.

Take away the shame of being exposed as being without some (considered to be) vital skill, experience, understanding, tool, or piece of information and you open up the possibility of having looser, yet more realistic project budgets and schedules.  While you might not like the added apparent cost, you will like the added certainty that you can plan around a product release date more reliably and may even have time in hand, if things go well.

Once the development team members lose the fear of being called inadequate imposters and of exposing their relative skills gaps, the team can work better together, as a team.  Time can be allocated to go find out what each needs to know.  In some cases, the false economy of hiring junior programmers is revealed, when this step happens.  You realise that some team members need to learn a lot more than others.

Most importantly, team members no longer try to conceal trouble, when they encounter something they don’t know how to solve, or have an incomplete understanding of what they are supposed to be building.  The phrase I have heard used is: “Don’t sit on anything smelly.”  The spirit of this motto is to ask team members to expose unknowns and issues early, when something can be done about them.  The corollary to sitting on something smelly is that it just gets smellier and smellier.

When you transparently and honestly expose to stakeholders what the development team needs to go and find out, before they can set more accurate expectations on budget, delivery time, feature set and quality, you either get the support and permission necessary (what other choice do the stakeholders have?) or else the project is shut down.  People fear unemployment as much as they fear being found wanting in skills and knowledge, so the temptation to lie, to keep a non-viable project going, is strong.  However, the truth always comes out.

A non-viable project reveals itself to be so, at some point, so better to have the stakeholders understand this and make an active management decision, before all the gnashing and wailing, rather than letting the train wreck happen and have to live with the downstream consequences.  If the project is viable and worth doing, then it’s going to be worth getting the development team up to speed with what they need to know to develop it well.  If it’s not, the project should never have been started in the first place.  Too many stakeholders start non-viable projects, on a wing and prayer, with insufficiently deep pockets, and then blame the technical staff for not being able to pull off the required miracle.

It is the responsibility of every development manager and software architect to explain to stakeholders that nobody knows everything and that the people in their team were hired on the basis of being agile-minded enough to go find out.  It is unrealistic and dishonest in the extreme to expect developers to know everything particular to the stakeholders’ business and software code, straight off the street.  It’s time to stop play acting and making promises that nobody can keep.