If the customers of the software written today cared about quality -- and they _should_ care about quality -- they'd demand a higher standard of quality for the money they are paying.
They don't, though. Firstly, the users aren't the customers. The customers are the advertisers or corporate buyers. Secondly, the users don't _want_ to be customers. They'd rather whatever they can get for free that anything that costs money, even if the thing that costs money could be orders of magnitude better.
The first thought I have: I think quality is inclusive of size, speed, and reliability. Quality is _also_ features and functionality. It is also user experience. Probably many other things too, but this is just off the top of my head.
I'm also not sure users would come rushing to the side of programmers if _they_ became the customers.
I am the customer of companies that make many other things in my life. The quality probably isn't what it could be if that consideration was put much more front and center. For many things, I am _fine_ with that.
For the same reasons, I don't think the users of software would be obviously wrong. Certainly I don't think they're obviously wrong enough for me to become preachy. If writing software that isn't to the level of quality I demand or need causes me existential dread, I am now willing to say that might be a "me" problem.
I don't see the current model as a single model, but as several models interrelating.
In software, there are at least three models I can think of immediately: code, configuration and user data.
Why do I separate configuration? Isn't configuration just code or data? I don't think it is. It is data _about_ a particular system, as opposed to a particular user.
Why the distinction here? The code of a system can be designed, developed, and tested against a set of supported configurations. At that point, the system might only run under one configuration at a time, but can be trusted from a requirements perspective to operate under other configurations without needing to go through the whole software development lifecycle again.
Why not just store this in user data, then? Different requirements. Three off the top of my head: configuration data wants much better change management than most user data does. That management wants to be exportable and importable. It wants different access controls.
Historically, configuration data change management has been done in SCM, such as git. The reason why git isn't a big deal in development is because it is not a point of particularly high friction relative to the other parts of the software development lifecycle. It is a _much_ bigger point of friction in configuration changes.
Hence, three models.
We can argue about whether or not configuration changes _ought_ to go through the full cycle, because I am wrong to trust _any_ change to a system with anything less. My practical experience suggests that most of the time, the damage done is less than the cost of enforcing a strict lifecycle on everything.
To make this concrete: terraform for me has been part code, part configuration.
I define a resource, and provide a whole set of knobs on that resource. That's the code part. I test that code against a variety of configurations, the same way I might unit test application code against a variety of app configurations. I also verify that changing knobs from one setting to another behaves. With automated testing, this actually isn't all that hard to do. Once I've verified things work right, I deploy.
At this point, I will default to trusting that things will work. This is the configuration part. Set these knobs to whatever permitted value you want, and the system will update behavior based on those new values. Most of the time, things like this work. That is good enough for me.
> A field which has so many tools to objectively quantify their work and the result so often are debates displaying poorly concealed biases and egos.
This felt wrong when I read it.
I agree we have many, many tools to objectively quantify aspects of our work.
Where I disagree: these tools only measure _some_ aspects. There are many aspects where we don't have good tools for measurement. Some of those aspects are for all practical purposes immeasurable.
For example: measure maintainability.
I think what happens then is the same thing that happens in politics. We take proxy metrics that _are_ measurable, and try to extrapolate over everything. The debates and egos come from arguing which proxy metrics should be weighted which way.
Then I realized I'd propose an alternative hypothesis: programming as a craft is immature.
I could never imagine civil engineers arguing over proxy metrics to the effects of natural forces on a bridge.
Can programming _become_ mature? I don't know. I'm skeptical of any claims that it can be. They all seem rooted in a gut sense of a particular weighting of what we can measure.
It seems many commenters in several threads are making the same point. I'll summarize it here:
> Creating an excessively competitive environment by working longer hours because of an ability and desire to do so is bad civic hygiene.
I can say I understand the sentiment. I personally very much dislike the bind someone puts me in if they do my job for cheaper. I dislike it _more_ when I see them suffering because of the choice they made. I think of the implications, and see a path toward everyone suffering. I want to hold that other individual responsible for increasing suffering in the world.
I take a beat. They've made a poor decision. Or maybe they haven't. Maybe they are suffering in ways I see, but not suffering in ways I don't see. Maybe they seem to be suffering more than they are. Can I do something else about my suffering _other_ than hold them responsible?
Example: are they _really_ normalizing mandated weekend work by voluntarily working weekends.
No? Then I think we can start talking about civic hygiene. I think civic hygiene is too complicated of a subject to shoot from the gut about. It is too complicated to reason about from a foundation of resentment.
It's the human equivalent of the race to the bottom. A company with deep pockets (or VC funding) might sell a product at or below cost to try to muscle out competitors. The end result is either a monopoly (where the company can then raise prices up to whatever profitable levels they want) or long-term lower prices and weak margins.
In the same way, an individual worker might want to work longer hours in order to be more attractive as a candidate for raises or promotions. But often management sees a small number of employees willing to do this, and then starts to expect all employees to do it. In the absence of unions or other collective action, the other employees are forced to keep up. They've raced their labor price to the bottom.
I agree with the "civic hygiene" angle: it's much healthier for people not to do this, and provide better working conditions for themselves and others. But that requires everyone to do the right thing all the time. There will always be enough people who want to get ahead, and are willing to make themselves miserable to do it. I don't think most are being malicious: they don't realize the societal effects of their actions. But those effects happen regardless.
The difficulty of collective action is really the heart of this. If every employee just up and decided one day that the standard would be a 32-hour work week, and people would only work Monday through Thursday, it would... actually happen. Companies would complain, threaten to fire people, fire some people after all. But if everyone could actually stick together for the greater good, it would work. But people can't do that, not 100%. Some can't for legitimate reasons ("I can't risk getting fired or I won't be able to pay rent / buy food / stay in the country"), and some won't for selfish reasons ("If I break ranks and lick the company's boots, I'll be rewarded").
There was a possibility I proposed, which I think you missed. Maybe they _aren't_ miserable. They might be suffering in some ways. They might even complain about it. That doesn't mean they are miserable. They may find other joy that makes up for the suffering.
If we can't agree on this, we'll probably not agree on anything else. It'll mean you've decided on a premise that I think is false. I'll just keep seeming ignorant to you.
_Should_ they be miserable? Perhaps. Maybe they have a false consciousness. Maybe they need to understand better the societal effects they are responsible for. These are debatable. To _presume_ this is true, though, seems to me kind of arrogant.
We could perhaps get better software, but at what cost?
One of the nice things about engineering disciplines is that costs can be reasonably forecast. There are spectacular counterexamples (e.g. Big Dig), but bear in mind those projects were much more than "just" engineering projects.
Software costs seem hard to forecast. Software integrates with other software. Software is created via a whole pantheon of algorithms. The "better" algorithm is often context dependent. That context depends on what else gets integrated. Did I mention we probably won't know at the design phase how things will be integrated?
Other engineering disciplines integrate with things that are well-known: the ground, water flows, the atmosphere. These things don't change. This is nice.
This article makes it sound like "better" is just a matter of spending more. My read is different: spend more and be correct. Correctness _isn't_ just something we know but aren't allowed to implement. In many cases, we don't _know_ what correct is. We have to _find_ correct via exploration and experimentation. Even when we do, we might severely misjudge the effort required to get there.
This complexity isn't just accidental. The world is a complex place. Our human minds act on a small portion of that complexity, based on all sorts of heuristics we aren't even conscious of. They work most of the time. The rest of the time? We're compelled to shoehorn things into our heuristics. This ends increasingly poorly the more complex the underlying mechanism is.
This is a hard argument to make to someone who will not accept that they are not correct. Correct in their criticism. Correct in their diagnosis. Correct in the the behaviors that lead to our condition. Correct in asserting that avoiding those behaviors would result in no unanticipated consequences. Resentful about it because they were correct, and we didn't accept that.
I'm going to ask a question that I fear will have me labelled as naively privileged almost beyond any hope of my eventually redemption.
Are we as individuals hopelessly trapped in a social fabric that leads to the kinds of bad outcomes based on abuse of data that the author describes?
Assuming we can escape, is our only way out of this fabric to shred it from within? What of the benefits that we shred in our zeal? Is it mistaken to even claim their are benefits to be weighed against the drawbacks, because the drawbacks are so bad?
Perhaps it is a naive question. Is there a way we can reduce the bad outcomes by making those that cause them irrelevant, rather than counter-engaging them directly?
> Are we as individuals hopelessly trapped in a social fabric
Yes and no. The trap you speak of is merely a frame designed to bind you. The simplest (yet effective) one is a false dichotomy: you're given a choice between similarly bad options A1 and A9, brushing under the rug options B and C. In a more advanced variety the compromise "A4" is setup first and the false dichotomy A1:A9 is built around it as two herding gate poles. A step up from there is a vicious attack on options B and C and any person who dares to bring them up.
Disposing of frames in your own mind is relatively easy assuming you can talk with a few smart people without fear of reprisal. Just keep an open mind about it - remember your goal is to break out of the frame, not to inflict your version of truth upon the unsuspecting universe (the urge itself, if you have it, needs to be confronted).
As to direct counteraction - that's just one of the frames you're stuck in. You assume that you either counter them, or you acquiesce to them, or hide from them. Did you notice that all three choices make things worse? That's a sure sign you're in a frame. The "cause them irrelevant" part is kind of right, except that it's the consequence, not the method.
It boggles my mind how much people will tend to treat negotiations, amongst so many other things, as zero-sum games. If that were true, anyone who claims this should please explain to all the people who entered into negotiated agreements and found mutual benefit how they are actually being screwed by the counterparty.
For those who believe negotiation is zero-sum, I will say to you: if you notice agreements around you tend to turn sour because a party in it feels like they got screwed, take note of the common element.
This includes salary and employment negotiation. Unless you are in a one company town, or otherwise have skills and talents that are transferable to nowhere than your present employer, you most likely have alternatives to explore. Even if this is the case, there are alternatives, although they will not be anywhere near as easy to achieve.
Even then, it is not every employer that will decide the best way to profits is to screw their employees, and hope they feel hopeless. This is but one way to affect the bottom-line, and often not a very effective one. People will be more productive when they don't feel like they are being shafted. Not just in salary, but in: career development; personal sanity; and, if they care and have an interest in such a thing, in the net outcome of the organization.
So, I absolutely agree with you. Do not stand for people who feel like they need to "win" because you'll invariably screw them back. They may ultimately add up to a great big loss for everyone involved.
This may depend upon where you are, and perhaps a number of other factors, but since we are mostly speaking in gross generalizations here, I will too.
I think you far oversell the degree to which people who are being recruited do not have at least one, and possibly far more than one, best alternatives to a negotiated agreement with the recruiting party. Anyone who was to say to anyone around me "you have no alternatives, this is it" will immediately trigger an inventory taking in my own mind of all the possible alternatives that person may have.
Ultimately, I agree about the well-oiled machines, though. It is unfortunate that some organizations end up being run like this. It is bad for them too, especially in a world where an operational mindset can be overturned seemingly overnight by a new, better, cheaper way of doing the same thing.
For people who want to stay where they are, but see this happening, my response to them would be to make this acutely obvious to those around them: both the state of things, and the consequences. Not all companies are in a harvest and exit mode. Some still want to grow, and their growth will be considerably less in jeopardy if they play an offensive game against the market. But, in order to that, they have to stop playing a defensive one against their own employees.
If they realize this, they'll quickly realize soon after that their best alternative is not to turn recruiting into a battle.
Another BATNA I would propose to the people around me is this: invent that better thing. Your new job can be to put the company that treated you like a cog out to pasture.
What I will say this: I don't believe fear of the big, bad recruiting machine is a best alternative to anything. I feel it is consideration of one alternative, realizing it might not work out well, and getting angry. There are other alternatives out there; there is no reason to act so powerless in front of this one.
I really hope people do not misunderstand this article.
Until I reminded myself to assume good faith about the author (which is usually worth it with this author), I felt myself assuming he was disparaging all things new as being shiny and therefore unprofessional.
I don't believe that is the point of this article, and I worry the caricature is a little so over the top that people will interpret it as such a little too easily.
I think the point is this: don't confuse movement with progress. New is not necessarily better. The world of software tools is like any other marketplace of ideas: you will have a curve of early adopters onto the stragglers. It is not worth assuming that a tool is worth upending the world over just because the early adopters are jumping up and down about how it will. Most things won't. But some things will.
The point isn't novelty. It is value. Novelty has value, particularly social and sentimental value, but often it is fleeting. Other forms of value aren't. It is worth considering the new thing in all perspectives of value.
We are creating a universal loyalty currency, akin to AmEx points, that users can spend on virtual and physical goods. We are growing rapidly, and have around 3 million active users each day across around 500 mobile applications.
We have been actively targeting the Android mobile market, and just recently released our SDK for iOS. We are in need of the most help from a couple of talented engineers to help maintain and extend these SDKs.
If you are more interested in either front or backend web development, or more of a generalist, we are definitely interested in talking to you as well.
You'd be joining a small but very talented and tight-knit team of developers working at all levels of the stack, from postgres up through rails and into the platforms I mentioned above. From my own personal experience so far, the environment here is amazingly hacker-friendly. You will be able to ship code early and often with zero red tape, be given a very large amount of autonomy, and feel your impact on the company every day.
If the customers of the software written today cared about quality -- and they _should_ care about quality -- they'd demand a higher standard of quality for the money they are paying.
They don't, though. Firstly, the users aren't the customers. The customers are the advertisers or corporate buyers. Secondly, the users don't _want_ to be customers. They'd rather whatever they can get for free that anything that costs money, even if the thing that costs money could be orders of magnitude better.
The first thought I have: I think quality is inclusive of size, speed, and reliability. Quality is _also_ features and functionality. It is also user experience. Probably many other things too, but this is just off the top of my head.
I'm also not sure users would come rushing to the side of programmers if _they_ became the customers.
I am the customer of companies that make many other things in my life. The quality probably isn't what it could be if that consideration was put much more front and center. For many things, I am _fine_ with that.
For the same reasons, I don't think the users of software would be obviously wrong. Certainly I don't think they're obviously wrong enough for me to become preachy. If writing software that isn't to the level of quality I demand or need causes me existential dread, I am now willing to say that might be a "me" problem.