One more tidbit from the (ongoing) deep-dive into ancient/classical Rome.
Latin and modern English pretty much agree on a broad definition of "patron." A patron looks out for something or someone. hen a customer patronises a business, s/he is interested in keeping it going--perhaps when there might be cheaper and/or more convenient equivalents. In the days when kings and nobles sponsored writers and artists, they were considered patrons. (Of course, a rising middle class meant that patronage tended to become more democratic, but the basic tenet still held.)
The resemblance ends there, however. The definition of patron (and the relationship between the patron and those he patronised) changed a bit over the centuries, but the basic idea ran more along the lines of reciprocal obligations.
Oddly, the patronised were called "clients," which sounds strange to modern ears, because the client in what was considered a socially inferior position--and, by definition, held less power. It doesn't map cleanly to the later feudal obligations of serf -> minor nobleman -> major nobleman -> king. But it was knit tightly into the social structure and roman ethos of trustworthiness.
A patron's obligations to his clients, depending on the time, could include financial support, brokering marriage arrangements, representing his client in court, use his influence to shield the client from the tax collector or to right some wrong done to the client.
The client would (most importantly) vote for his patron. But (again depending on the century), he might go to war with his patron. Or provide what services he was capable of performing. He might contribute money to the patron's efforts (political campaigning or religious services). If the client was powerful enough to have clients of his own, those sub-clients might be put to the use of the patron.
The eye-opening facet of this relationship was that it was binding on one's heirs. In essence, it became quasi-familial. Patrons and clients could not testify against each other in court. If a client died without an heir, his patron would inherit his property. That freed slaves automatically became clients of their owner was no surprise, but people conquered by a Roman army would (again, in certain points in history) be considered "clients" of the commanding general. Or the Emperor (which was sometimes one and the same).
Today, the only echo of this relationship can be found in the attorney-client / doctor-patient / confessor-sinner relationship. All are to some extent protected by law and professional ethics in a way that other business relationships aren't.
(Of course, in I/T, "client" has another meaning entirely. But rather than a client-patron relationship, it's a client-server relationship, which is where our definitions really go off the rails...)
When you dabble (as I do) in etymology, you're used to meanings outgrowing their words, or sometimes shrinking within them. And sometimes the meanings almost turn themselves inside out. As a business owner, I thought it was interesting how the meaning of client transitioned from one who relied on someone more powerful (sometimes for their sustenance) to the person who really holds the power in the relationship. Thus, client and patron have become almost equivalent in meaning, at least from a business's standpoint.
- - - - -
* A wink to the Zero Mostel vehicle.
Thursday, July 30, 2015
Monday, July 27, 2015
The Roman(ce) of organisation
I was a little under the weather a few days ago--just enough to take the edge off. Sometimes the internet (by which I mean being sucked into the ADHD maelstrom of social media or the news) is the wrong kind of distraction. Instead, I ended up going down a different (albeit rather more focused) rabbit-hole: Roman history of the classical period.
Dennis is fascinated by Roman history. But, then, he's more or less the military historian of the household. And, let's call a spade a shovel here--the Roman empire was basically organised around conquest more than trade.
A lot of noise is made about the proverbial bread and circuses (particularly by the libertarian right) being the eventual downfall of Roman civilsation. That's far, far too facile. Bread and circuses? Really? When the military and the government come to operate hand-in-glove? And the military largely consists of large private armies loyal to a single leader? And the empire has to invade new territories to pay off the soldiers recruited after conquering those soldiers' territory?
That's basically a Ponzi scheme--with all the hallmarks of a tin-pot dictatorship besides. We all know how those schemes--and sometimes even the dictators-- eventually end. (Shocking precisely no one, Rome once had four Caesars in a single year.)
Plus, Rome's dependence on slavery--on average, one in three residents was a slave--gave little incentive for advancing technology. Plus, the slave trade was one of the more lucrative aspects of war-mongering. Which, of course left even less incentive for inventing labour-saving devices.
Now. I'm not saying that Dennis isn't correct. The Romans were straight-up fascinating. Most notably for their organisational skills. (To me, the obsessive organisation of the Roman armies is far more interesting than tactics, battles or campaigns. Making vs. breaking and all that...)
After all, it's not like war-mongering made them unique in the ancient Western world (or probably any other place and time in human history, really). Neither did slavery: Romans were rank amateurs compared to, say, Spartans Nor did religion--theirs was a mongrel mish-mash based somewhat on the cosmology borrowed from Greece, but with plenty of Etruscan leftovers and cults imported from as far afield as Persia (modern Iran). (And that doesn't even count those pesky mono-theists like the Hebrews and Christians who showed up in the middle of the story.) Culture? Nope--classical Rome had a decided inferiority complex: "Real" intellectualism came from (or imitated) Greece.
But nonetheless, time has been kind to the Roman legacy in the Western world. Take away the letters "J," "K," "U," and "W," and you have the Latin alphabet. (Mercifully, however, their numbering system has largely been left by the wayside in favour of the more sensible Arabic one. Want to know why Star Wars takes place "a long time ago"? Because they're using Roman numerals for the episode numbers. Just sayin'.) Until a couple of centuries ago, their language was still the lingua franca of the educated elite. Five modern languages are derived from Latin: Spanish, Portuguese, French, Italian, and Romanian. (And let's not forget that roughly one in three English words derives from French.) The Western calendar (with some corrections and innovations like the leap year) is largely their legacy.
Part of that is, of course, the legacy of Empire--particularly one that stretched from the middle of the U.K. to Istanbul. Flexibility in adapting to local customs and politics is a virtue, but flexibility in language and standards (e.g. measurements, dates) is the short road to administrative suicide. On the flip side, in a world where people are used to squabbling with their nearest neighbours from time immemorial, adopting the systems of the Empire means that no one actually has to compromise. (Human beings are awesome, amirite? [eyeroll])
In a milieu where even the longest-lived empires (e.g. the classical Greeks) didn't survive much more than a few hundred years, the Romans--despite the serious flaws in their civilisation--could hold out for roughly a millennium.
And yet today, "organisational skills" is such a throwaway term--the kind of fluff one puts on a resume or emphasises in an interview as part of the ritualised employment dance. As a liberal arts graduate, I've had a quarter-century to shake my head over how "communication skills" are treated much the same way--universally demanded, but rarely valued. It was only after reflecting on the classical Romans that I realised that talent in organisation falls into the same category.
In that light, I suppose it comes as no surprise (in an age of rock star CEOs) that we all know who Julius Caesar is, but take for granted the much larger legacy of often anonymous census-takers, accountants, lawyers, tribunes, consuls, engineers, scribes, et. al. who gave cohesiveness to what otherwise might have been a flash in the pan based on a handful of military victories.
Dennis is fascinated by Roman history. But, then, he's more or less the military historian of the household. And, let's call a spade a shovel here--the Roman empire was basically organised around conquest more than trade.
A lot of noise is made about the proverbial bread and circuses (particularly by the libertarian right) being the eventual downfall of Roman civilsation. That's far, far too facile. Bread and circuses? Really? When the military and the government come to operate hand-in-glove? And the military largely consists of large private armies loyal to a single leader? And the empire has to invade new territories to pay off the soldiers recruited after conquering those soldiers' territory?
That's basically a Ponzi scheme--with all the hallmarks of a tin-pot dictatorship besides. We all know how those schemes--and sometimes even the dictators-- eventually end. (Shocking precisely no one, Rome once had four Caesars in a single year.)
Plus, Rome's dependence on slavery--on average, one in three residents was a slave--gave little incentive for advancing technology. Plus, the slave trade was one of the more lucrative aspects of war-mongering. Which, of course left even less incentive for inventing labour-saving devices.
Now. I'm not saying that Dennis isn't correct. The Romans were straight-up fascinating. Most notably for their organisational skills. (To me, the obsessive organisation of the Roman armies is far more interesting than tactics, battles or campaigns. Making vs. breaking and all that...)
After all, it's not like war-mongering made them unique in the ancient Western world (or probably any other place and time in human history, really). Neither did slavery: Romans were rank amateurs compared to, say, Spartans Nor did religion--theirs was a mongrel mish-mash based somewhat on the cosmology borrowed from Greece, but with plenty of Etruscan leftovers and cults imported from as far afield as Persia (modern Iran). (And that doesn't even count those pesky mono-theists like the Hebrews and Christians who showed up in the middle of the story.) Culture? Nope--classical Rome had a decided inferiority complex: "Real" intellectualism came from (or imitated) Greece.
But nonetheless, time has been kind to the Roman legacy in the Western world. Take away the letters "J," "K," "U," and "W," and you have the Latin alphabet. (Mercifully, however, their numbering system has largely been left by the wayside in favour of the more sensible Arabic one. Want to know why Star Wars takes place "a long time ago"? Because they're using Roman numerals for the episode numbers. Just sayin'.) Until a couple of centuries ago, their language was still the lingua franca of the educated elite. Five modern languages are derived from Latin: Spanish, Portuguese, French, Italian, and Romanian. (And let's not forget that roughly one in three English words derives from French.) The Western calendar (with some corrections and innovations like the leap year) is largely their legacy.
Part of that is, of course, the legacy of Empire--particularly one that stretched from the middle of the U.K. to Istanbul. Flexibility in adapting to local customs and politics is a virtue, but flexibility in language and standards (e.g. measurements, dates) is the short road to administrative suicide. On the flip side, in a world where people are used to squabbling with their nearest neighbours from time immemorial, adopting the systems of the Empire means that no one actually has to compromise. (Human beings are awesome, amirite? [eyeroll])
In a milieu where even the longest-lived empires (e.g. the classical Greeks) didn't survive much more than a few hundred years, the Romans--despite the serious flaws in their civilisation--could hold out for roughly a millennium.
And yet today, "organisational skills" is such a throwaway term--the kind of fluff one puts on a resume or emphasises in an interview as part of the ritualised employment dance. As a liberal arts graduate, I've had a quarter-century to shake my head over how "communication skills" are treated much the same way--universally demanded, but rarely valued. It was only after reflecting on the classical Romans that I realised that talent in organisation falls into the same category.
In that light, I suppose it comes as no surprise (in an age of rock star CEOs) that we all know who Julius Caesar is, but take for granted the much larger legacy of often anonymous census-takers, accountants, lawyers, tribunes, consuls, engineers, scribes, et. al. who gave cohesiveness to what otherwise might have been a flash in the pan based on a handful of military victories.
Monday, July 20, 2015
Beware the fair-weather meteorologist
Today, as a favour to a client, I spent about an hour on the phone with a consultant who was helping him be reimbursed for some of the cost of "our" application via a government program. The aim of the program is to promote research and development into new products/designs...even when those things don't necessarily pan out.
This app. certainly qualifies in that regard: At the start, we had no idea that it would even work. Two years and a few significant adjustments later, we're still rolling the bones on each iteration.
My part in this interview was to basically tell the story of each stage in the application from a boilerplate format something like this:
Uhhmmmm, there's no such thing as those kinds of things. I only sit on problems long enough for one of the following to happen:
Option A: I have (at a minimum) a strong gut-level diagnosis plus a plan to verify/disprove that hypothesis.
Option B: No immediate diagnosis is forthcoming, but I know exactly where I'm going to start looking.
Arriving at either option shouldn't take very long. Half an hour, maybe. Basically, experience/instinct kicks in...or it doesn't and my Google-fu skills get a workout.
But that's not really the important part. What's important is choosing to work with clients who understand that freaking out at problems only makes them harder to solve. Not only the problem(s) at hand, but future problems as well.
Sure, freak-outs guarantee that you (as a client) won't hear about a lot of the small problems--at least not the kind that are easily and quietly fixed. Maybe you'll sleep better for that. At least until the less-easily-fixable small problems fester into big ones. All because energy that could have been spent on diagnosis is instead channeled into suppressing the symptoms. (And let's not even count the time wasted on blame-slinging and finger-pointing.) I have no sympathy for a client relationship run on a "no bad news" principle. It's tantamount to only accepting sunny forecasts from the meteorologist. Or buying stocks from perpetually bullish brokers. Die of pneumonia in the poor-house, and who's to blame, really? Exactly.
Yes, I realise that no one likes to report (much less hear about) project line-items slipping a schedule date, or costing more than initially budgeted. Or that off-the-shelf software will require more customisation than advertised. Or that a Zero-day security hole has to be patched and rushed out the door in the middle of a release cycle. Or that Google/Facebook/Bing/Microsoft/Apple/PayPal/Etc. has arbitrarily changed their terms of service. Or that a massive DDOS attack is measurably impacting an app.'s response times. Whatever. Stuff happens. Professionals deal with it.
In lieu of falling into a "no bad news" mindset, here's an alternative. You (again meaning the client) can't insist that there will be no bad news. At least without everybody knowing you're on holiday from Reality.
But you can--within reason--insist on no surprises. Obviously, things like security flaws, third party service failures, etc. aren't always predictable. (Hence, the "within reason" qualifier.) Developers, you can insist on a working in a No Freak-out Zone as the price of landing no surprises. (Pro tip: If you're not sure about the client's commitment to the "no surprises" credo, find a small, no-brainer problem to test the waters. Bring it--and your plan to fix it--to the client in person or over the phone. None of this passive-aggressive end-of-the-week-hoping-they've-already-left email nonsense. Nope. Own it.)
Eliminate the freak-outs, minimise the surprises, and the a lot more of the problems will sort out much sooner. After over a decade in software, I can pretty much promise you that.
This app. certainly qualifies in that regard: At the start, we had no idea that it would even work. Two years and a few significant adjustments later, we're still rolling the bones on each iteration.
My part in this interview was to basically tell the story of each stage in the application from a boilerplate format something like this:
- What was the problem we were facing?
- What did we do to address the problem?
- Did it work according to expectation?
- If so, by how much?
- Or if not, by how much?
- What unexpected problems/obstacles (if any) cropped up?
Uhhmmmm, there's no such thing as those kinds of things. I only sit on problems long enough for one of the following to happen:
Option A: I have (at a minimum) a strong gut-level diagnosis plus a plan to verify/disprove that hypothesis.
Option B: No immediate diagnosis is forthcoming, but I know exactly where I'm going to start looking.
Arriving at either option shouldn't take very long. Half an hour, maybe. Basically, experience/instinct kicks in...or it doesn't and my Google-fu skills get a workout.
But that's not really the important part. What's important is choosing to work with clients who understand that freaking out at problems only makes them harder to solve. Not only the problem(s) at hand, but future problems as well.
Sure, freak-outs guarantee that you (as a client) won't hear about a lot of the small problems--at least not the kind that are easily and quietly fixed. Maybe you'll sleep better for that. At least until the less-easily-fixable small problems fester into big ones. All because energy that could have been spent on diagnosis is instead channeled into suppressing the symptoms. (And let's not even count the time wasted on blame-slinging and finger-pointing.) I have no sympathy for a client relationship run on a "no bad news" principle. It's tantamount to only accepting sunny forecasts from the meteorologist. Or buying stocks from perpetually bullish brokers. Die of pneumonia in the poor-house, and who's to blame, really? Exactly.
Yes, I realise that no one likes to report (much less hear about) project line-items slipping a schedule date, or costing more than initially budgeted. Or that off-the-shelf software will require more customisation than advertised. Or that a Zero-day security hole has to be patched and rushed out the door in the middle of a release cycle. Or that Google/Facebook/Bing/Microsoft/Apple/PayPal/Etc. has arbitrarily changed their terms of service. Or that a massive DDOS attack is measurably impacting an app.'s response times. Whatever. Stuff happens. Professionals deal with it.
In lieu of falling into a "no bad news" mindset, here's an alternative. You (again meaning the client) can't insist that there will be no bad news. At least without everybody knowing you're on holiday from Reality.
But you can--within reason--insist on no surprises. Obviously, things like security flaws, third party service failures, etc. aren't always predictable. (Hence, the "within reason" qualifier.) Developers, you can insist on a working in a No Freak-out Zone as the price of landing no surprises. (Pro tip: If you're not sure about the client's commitment to the "no surprises" credo, find a small, no-brainer problem to test the waters. Bring it--and your plan to fix it--to the client in person or over the phone. None of this passive-aggressive end-of-the-week-hoping-they've-already-left email nonsense. Nope. Own it.)
Eliminate the freak-outs, minimise the surprises, and the a lot more of the problems will sort out much sooner. After over a decade in software, I can pretty much promise you that.
Monday, July 13, 2015
In scripto veritas*
The last few (work)days have been a blast back to my DOS past--at least in the sense of being very script-oriented. (The similarities end there. My first computer, an 8-bit Epson 8088, was powered by two 5.25" floppy drives and was certainly not networked.) I've had the luxury of a web-based interface to the MySQL database, but otherwise all interaction with this new server has been via SSH, SCP, and SFTP. White text on the black background of a command-prompt, in other words.
Threading through the maze of branches of a file system (in the case of SFTP, on the client- as well as server-side) definitely requires a bit more presence of mind than a "windowed" UI. Particularly when you need to make sure you're not uploading Beta code to a Production system...or vice-versa. Then there's the fact that misspelling anything will generate an error message. And in a Unix-based system, that means even perfectly matching the capitalisation.
But oddly, the lack of a pretty UI over the top of those interactions is oddly reassuring. When I launch a script via a command-line and collect its output from a log file, I feel like I can trust what it's telling me. Ditto when keeping an eye on the system processes after a scheduled (a.k.a. "cron") job launches. Maybe it's just that I was "raised" on the command-line. Or maybe it's the fact that *nix doesn't try to protect its users from their own fumble-fingering or short attention spans.
Either way, I appreciate the straight-talk. Normally, I distrust truth rendered in terms of black-and-white. But this is definitely an exception.
- - - - -
* I'm riffing on the Latin "in vino veritas," which translates as, "In wine, [there is] truth."
Threading through the maze of branches of a file system (in the case of SFTP, on the client- as well as server-side) definitely requires a bit more presence of mind than a "windowed" UI. Particularly when you need to make sure you're not uploading Beta code to a Production system...or vice-versa. Then there's the fact that misspelling anything will generate an error message. And in a Unix-based system, that means even perfectly matching the capitalisation.
But oddly, the lack of a pretty UI over the top of those interactions is oddly reassuring. When I launch a script via a command-line and collect its output from a log file, I feel like I can trust what it's telling me. Ditto when keeping an eye on the system processes after a scheduled (a.k.a. "cron") job launches. Maybe it's just that I was "raised" on the command-line. Or maybe it's the fact that *nix doesn't try to protect its users from their own fumble-fingering or short attention spans.
Either way, I appreciate the straight-talk. Normally, I distrust truth rendered in terms of black-and-white. But this is definitely an exception.
- - - - -
* I'm riffing on the Latin "in vino veritas," which translates as, "In wine, [there is] truth."
Monday, July 6, 2015
The irony of "Internet time"
Normally, moving code and data from one server to another is something I try to do in the middle of the weekend (e.g. late Saturday night). Alas, even the best-calculated schedules sometimes are thrown awry. In this past weekend's move--a.k.a. "migration"--I was actually ahead of the usual curve of permissions not being correctly set up (which is normally the biggest show-stopper). But then my connection to the server would drop intermittently.
I've chosen the new hosting company for this application (and others yet to come) largely based on the fact that customer service is a matter of sending an email or picking up the phone. Not punting a form submission into a queue picked up halfway around the globe.
True to form, debugging has been ongoing since Saturday evening, and the preliminary diagnosis is a DNS issue.
Now, if you're not in I/T, the only thing you really need to know is that DNS (or the Domain Name System) basically functions as the phone book of the internet. Networked servers, just like phones, are known by a number. But we humans know the people (and companies) associated with those phones as names. So, just as you would search WhitePages.ca by name (and city) to find a number, your web browser queries a DNS server to translate the human-readable "www.duckduckgo.com" to the network address "107.21.1.61."
That lookup and translation happen so immediately and (usually) so seamlessly that it's easy to take for granted. (Unless, of course, you're a Rogers customer.) Until it doesn't work and a website you know is legit. 404s.
Unlike many other networking issues, DNS problems can take a long time to completely resolve. The reason is that when a web URL moves from one server (which is a number, remember!) to another, it can drop off the internet's radar. That's because not all DNS servers update at the same rate--some of them can take up to 72 hours. It's the price we pay for the decentralisation (and thus the robustness) of the internet.
But boy howdy, does a potential 3-day lag ever slow down debugging. Not to mention that having a key feature of the modern internet move so glacially feels more than a bit ironic when everything else has been speeding up over the past 20+ years. But it's not like irony and the internet are strangers, right?
I've chosen the new hosting company for this application (and others yet to come) largely based on the fact that customer service is a matter of sending an email or picking up the phone. Not punting a form submission into a queue picked up halfway around the globe.
True to form, debugging has been ongoing since Saturday evening, and the preliminary diagnosis is a DNS issue.
Now, if you're not in I/T, the only thing you really need to know is that DNS (or the Domain Name System) basically functions as the phone book of the internet. Networked servers, just like phones, are known by a number. But we humans know the people (and companies) associated with those phones as names. So, just as you would search WhitePages.ca by name (and city) to find a number, your web browser queries a DNS server to translate the human-readable "www.duckduckgo.com" to the network address "107.21.1.61."
That lookup and translation happen so immediately and (usually) so seamlessly that it's easy to take for granted. (Unless, of course, you're a Rogers customer.) Until it doesn't work and a website you know is legit. 404s.
Unlike many other networking issues, DNS problems can take a long time to completely resolve. The reason is that when a web URL moves from one server (which is a number, remember!) to another, it can drop off the internet's radar. That's because not all DNS servers update at the same rate--some of them can take up to 72 hours. It's the price we pay for the decentralisation (and thus the robustness) of the internet.
But boy howdy, does a potential 3-day lag ever slow down debugging. Not to mention that having a key feature of the modern internet move so glacially feels more than a bit ironic when everything else has been speeding up over the past 20+ years. But it's not like irony and the internet are strangers, right?
Thursday, July 2, 2015
"How much do you charge to make a website?"
That's a fair question, and as a freelance programmer, the very last thing I will do is roll my eyes at it. It's just that, when it's asked, I am often the least qualified person to answer it.
Here's why.
But first, a story.
The real estate agent who schlepped us all over La Crosse, WI to help us find our house was an interesting--and instructive--character. From him I learned the adage, "The head of the fish stinks first." Also that home-canned beets don't taste horrid like commercial ones. ("Look at me, Doreen: I know food.") And the location of the best coffee shop Downtown.
But he also hammered something into my brain that should have been learned while shopping for our first house: The "true" price of the house is the price at which it's sold.
That sounds a bit like a solipsism, but it's actually a little more Zen than that. See, when you buy a house, the price you will pay for it is actually the result of a number of constraints pulling in different directions. And only one of those constraints, I must stress, is the budget.
For instance...
Constraint: Family. Who's going to have to share a bedroom? How much schedule-Tetris in the bathrooms will be involved getting everyone out the door in the morning? Is there enough yard to kick the kids off the XBox and into the outside during better weather?
Constraint: Proximity to Work/School. Long work commutes suck, which definitely puts a radius on the feasible options. But if some schools have better reputations than others, that will shut down even more options. Or maybe the converse is true--maybe you just want to put as much distance as possible between yourself and the rest of everybody.
Constraint: Resale Value. Most homebuyers don't plan on coming out the door the last time in a toes-up state. Is the neighbourhood gentrifying or showing signs of hitting the skids?
Constraint: Upkeep. Really, how house-proud are you? Are you buying it with visions of Norman Rockwell Thanksgiving dinners dancing in your head?
Constraint: Amenities. Is single-story required for someone less mobile? How about shop space? A dry basement for all those boxes you're not going to get around to opening...maybe not until the next move to see what the heck you put in them this time? Is going off the grid (even if only after extreme weather) a priority?
The point is that a lot of different--maybe even conflicting--priorities have to be juggled. Each non-negotiable moves the price up, while compromises often nudge it down.
But here's the thing: You can't start house-shopping until you do two things:
Similarly, the cost of a made-to-order software application is (at least partly) a function of your priorities. And until those questions are answered to your own satisfaction, the cost of matching them can't be answered, either by you or the developer.
There's one critical difference between a house and an app., however: The "value" of your house is largely bounded by where, geographically, you are willing and able to hang your hat. You may be able to move the needle only so much on that. A secondary difference is that the math of determining exactly how much something (e.g. a baby barn) is really worth is pretty fuzzy because it's mixed up with so many other factors.
When, on the other hand, you have to turn away business because you don't have a way of keeping tabs on everything currently in the pipeline, "value" is mere accounting. Ditto failure rates or schedule slips. And if it's not mere accounting at this point, please don't waste your money/time by pulling in a software developer until you do have a price tag on that pain.
Now, it's possible that development and associated costs could add up to more than the problem they're meant to solve. No matter what Silicon Valley tells you, there are still some things better done by human intelligence. But the problem at least places an upper bound: Any solution must provide a return on investment.
The best assurance of recouping that investment is to make sure that the developer has as thorough an understanding of the problem as you do. (Pro tip: If a developer leads off the meeting with more answers than questions, find another one.) After that point, "How much do you charge?" is a completely reasonable question to ask. But not before, please.
Here's why.
But first, a story.
The real estate agent who schlepped us all over La Crosse, WI to help us find our house was an interesting--and instructive--character. From him I learned the adage, "The head of the fish stinks first." Also that home-canned beets don't taste horrid like commercial ones. ("Look at me, Doreen: I know food.") And the location of the best coffee shop Downtown.
But he also hammered something into my brain that should have been learned while shopping for our first house: The "true" price of the house is the price at which it's sold.
That sounds a bit like a solipsism, but it's actually a little more Zen than that. See, when you buy a house, the price you will pay for it is actually the result of a number of constraints pulling in different directions. And only one of those constraints, I must stress, is the budget.
For instance...
Constraint: Family. Who's going to have to share a bedroom? How much schedule-Tetris in the bathrooms will be involved getting everyone out the door in the morning? Is there enough yard to kick the kids off the XBox and into the outside during better weather?
Constraint: Proximity to Work/School. Long work commutes suck, which definitely puts a radius on the feasible options. But if some schools have better reputations than others, that will shut down even more options. Or maybe the converse is true--maybe you just want to put as much distance as possible between yourself and the rest of everybody.
Constraint: Resale Value. Most homebuyers don't plan on coming out the door the last time in a toes-up state. Is the neighbourhood gentrifying or showing signs of hitting the skids?
Constraint: Upkeep. Really, how house-proud are you? Are you buying it with visions of Norman Rockwell Thanksgiving dinners dancing in your head?
Constraint: Amenities. Is single-story required for someone less mobile? How about shop space? A dry basement for all those boxes you're not going to get around to opening...maybe not until the next move to see what the heck you put in them this time? Is going off the grid (even if only after extreme weather) a priority?
The point is that a lot of different--maybe even conflicting--priorities have to be juggled. Each non-negotiable moves the price up, while compromises often nudge it down.
But here's the thing: You can't start house-shopping until you do two things:
- Identify your priorities--i.e. why are these things important?
- Sort out their pecking-order--i.e. why are some more important than others?
Similarly, the cost of a made-to-order software application is (at least partly) a function of your priorities. And until those questions are answered to your own satisfaction, the cost of matching them can't be answered, either by you or the developer.
There's one critical difference between a house and an app., however: The "value" of your house is largely bounded by where, geographically, you are willing and able to hang your hat. You may be able to move the needle only so much on that. A secondary difference is that the math of determining exactly how much something (e.g. a baby barn) is really worth is pretty fuzzy because it's mixed up with so many other factors.
When, on the other hand, you have to turn away business because you don't have a way of keeping tabs on everything currently in the pipeline, "value" is mere accounting. Ditto failure rates or schedule slips. And if it's not mere accounting at this point, please don't waste your money/time by pulling in a software developer until you do have a price tag on that pain.
Now, it's possible that development and associated costs could add up to more than the problem they're meant to solve. No matter what Silicon Valley tells you, there are still some things better done by human intelligence. But the problem at least places an upper bound: Any solution must provide a return on investment.
The best assurance of recouping that investment is to make sure that the developer has as thorough an understanding of the problem as you do. (Pro tip: If a developer leads off the meeting with more answers than questions, find another one.) After that point, "How much do you charge?" is a completely reasonable question to ask. But not before, please.
Wednesday, July 1, 2015
Subscribe to:
Posts (Atom)