Anti-patterns and malpractices in modern software development (2015)

In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.

Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.

> write good code within the constraints of a fast paced business environment [...] It’s not always vital to the business to have a good code base.

You're on the edge of contradicting yourself.

If the business environment is fast paced, ie your development process for ingesting features and specifying behavior is ad hoc, ("we are agile/do scrum, except we service requests from customers immediately as they come in instead of waiting until the next sprint") it's absolutely vital to the business to have a good code base.

Being able to make rapid changes without breaking everything requires a good code base. If your code base is full of landmines, you necessarily cannot send an average coder out to implement some average feature, because they'll necessarily have to (re-)teach themselves about half the idiosyncrasies of the codebase before they can do anything.

It's fine to have a shitty code base if your business environment moves stodgingly. ("You want a new form in the UI? OK great! We need a scope of work, a formal specification, we will charge you by the hour, you will need to pay us to recertify the entire product. Let's set up a meeting with contracting and legal next quarter to iron out the details.")

In my experience, the people who implement features quickly in a shitty codebases do so by breaking stuff in non obvious ways. This includes myself. This is fine for my organization because we only ship once every six months, and we only ship anything after two months of exhaustive manual testing. If the organization just decided, "we're a fast paced organization now, now we ship every two weeks" we'd lose all our customers fairly quickly as a result of the precipitous decline of the quality of our product.

I suppose fast paced business environment+shitty codebase is also ok if the goal is just to sell the company as soon as possible. But that's a personal objective, (and a selfish one) not a business objective.

I've worked with such people and on applications made by them.

All that is usually done at the expense of others - be it teammates or future maintainers.

It works great for MVPs and such, but falls flat on its face when you have to add new features to a three year old application, whose original creator moved on a while ago.

>> “business people” ... and they typically make decisions in order to maximize good business outcomes.

You had me until this statement. It's been my observation that "business people" are usually self-interested manipulators who hire people they don't need if it makes them look important, game/trick OKRs, hide all failures from their superiors (and would fire you if you went behind their back), often damage brand trust/equity to try to get good metrics for a quarter (e.g. google), willingly let massive problems (e.g. security holes a la equifax) fall on the floor rather than risk being associated with problem by helping.

Not all, but more than half.

I would not call it 'complaining' to point out a business constraint, I would call it part of the job.

To make it easier there really are only 2 business constraints: Time and Money. Everything can roll up to one or both of those.

I'd also like to note that asking an engineer to estimate a project, is work. That work (creating the estimate) takes both time and money. The more time and money engineers spend on creating an estimate, the more accurate (and valuable) it will be.

Here. This is an estimate for almost every business software project: Between $0 and $100MM. That took me no time and as a result, has no value.

The other end of that spectrum is an estimate with perfect accuracy and full value. Meaning -- we know, to the penny, what it is going to cost. An estimate like that is going to be EXPENSIVE and might even eclipse the cost of the entire software project.

Knowing that creating estimates take time and money, the question inevitably becomes "Well how much will it take to create the estimate?"

The answer comes down to: How much do you want to invest in it? Or better put: How important is estimate accuracy to you?

Business people decide the value of things, rely on that. "What is the dollar value of this to the business?" is a legitimate question to ask to a business person. If it's worth $1, then use my estimate above. If it's worth $1MM then the next question is: What percentage of that inevitable end value is it worth to spend on the estimate?

Most of the time the number that comes back is not derived from some magical corporate formula, it's gut feel. Which by the way is essentially arbitrary, which I wouldn't call useless. But let's call it what it is, it's a number that is palatable to the business to lose.

So, given that number, we now know how much time to spend. Your accuracy will directly reflect that amount. If we want to be more accurate, we'll have to spend more money.

Business people are responsible for the money and engineers can not manufacture more time.

Rely on both of those.

I think what you mean is: the best programmers I know add value to the company.

As a freelance programmer I had to learn this. Companies don't give anything about the language, the VCS, the LOC, spaces or tabs, or anything unrelated to them.

You just add value to the company by creating great software they can use. This also means software that can be maintained and updated.

Some people in this thread complain about the "They don’t complain about business constraints". But when you start complaining about their business constraints, how can you add value to their business? You can only add value when you think about how you can create something that works best for them to keep those constraints. And ofcourse this includes discussing constraints when you are sure you have a great idea to make them better, but most of the time other people thought better and harder about those constraints than you did.

Edit: maybe it is unclear what you mean by "business constraints". In my mind you are talking about the company business, but others might thing about programming business logic.

> “business people” most often do understand what makes the money flow through their company

My anecdata for the last 15+ years doesn't support this claim.

This sounds exactly like the kind of engineers I never want to work with. That's just a breeding grounds for yes men with zero interest in challenging the status quo. Nothing personal, but you are the type of director I would also not like to work with. Three management style described sounds like a walking, talking red flag.

I am just a fair programmer.

But I create great insights. Whole new ways to see a problem. Making the intractable and complex simple and obvious with a novel mental model.

For instance, I replaced a high end CAD/Illustrator style print production workflow with a simple form. Answer some questions and out pops a production plan.

It took me 4 years to earn that insight. The entire industry modeled the flow information exactly backwards (https://en.wikipedia.org/wiki/Job_Definition_Format). It took me forever to overcome my initial misunderstand of the problem -- I mean really, how conceited am I to think everyone else is wrong and no one else thought of this before me -- and see the problem like the production workers do. I had to bridge the domains of print production and software design.

Alas, it's been a while since I've had a gig which could afford that kind of investment. My last gig, recommenders for fashion, which turned out to be a complete hoax, devs were slaves to JIRA, "just do 80%" and move on, throw everything away every 2 years, unless it's "legacy", in which case just suffer with it.

I wonder if there's much room left for dinosaurs like me.

> It’s not always vital to the business to have a good code base.

Many engineers may cringe at this... but this is true. Code is only as good as it is able to fulfill a business need: that is help the organization meet its strategic goals.

Technical constraints - maintainability, security, performance,... - are really subservient to that principle.

That is, they aren't unimportant. Rather, their importance is relevant - or a priority - in so far that they help achieve the higher goals.

... but this isn't a universal maxim!

> Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.

An employer/employee relationship is very much a business deal between humans. An employee sells expertise and potential for a fixed amount of time in exchange for a fixed salary. As with any deal, such business relationships extend beyond simple monetary compensation. Especially because employees subjugate themselves to the authority of their employer, making it inherently a skewed relationship.

When humans invest their time and effort in a venture, they hope to get a due sense of satisfaction and self-actualization from doing so. That's where aligning values makes all the difference.

What many business people fail to see is that employees don't identify themselves as resources, liabilities or labor. They see themselves as partners who hope to make a meaningful contribution, and they are willing to do so provided that they are treated as such: with a due sense of empathy and respect for their opinions, what motivates them to come to work each day; and so on.

If they don't get that, two things might happen. Either employees will walk out rather quickly, or - worst - they stay and will only give you the bare minimum of their efforts - living for the weekends - wasting both their own and your time.

It's true that companies aren't obligated to keep employees forever or that they can be let go if both parties want different things ...

... but publicly stating that any employer/employee relationship is "replaceable" without that nuance, is the shortest route towards foundering any hopes to attract potential hires who care about your business at all.

> They don’t complain about business constraints and they put out stellar work.

Given the above, humans will also factor in the moral and ethical side of what they are doing. And they can, will and should criticize those business constraints if those don't align with what they feel is "good" or "morally sound".

Business constraints aren't just limited to implementing some weird feature. That's just the output of a business constraint. Neither are styling rules or automated tests business constraints. Nope. it's far more then that. It's workplace culture as a whole. It's the shared values that are espoused on a day-to-day basis by everyone.

It's normal to have some level of conflict or tension as the net result is an ever-moving compromise.

Expecting that employees will never complain and only put out stellar work pretty much makes any healthy discussion moot. It's a non-argument as "stellar" is only meaningful in the eye of the beholder. All it does is create the perception that employees are seen as automatons.

Again, when employees pick up on this; they will either walk out or - worst - stick around and waste yours and their own time only doing the bare minimum to cash a paycheck.

In the short run, the bottom line of a company may reflect the financial benefits of optimizing for efficiency. But in the long run; not taking the human factor into account isn't sustainable at all. Neither for the employees, nor the business owners.

Not every business model is the same.

When you only have short term goals, sustainability is doesn't make sense.

@ismejeff, sorry but you are (probably) a business person.

- is an IDE open on your desktop right now?

- how many commits have you done this year?

Talking about code and software isn't anywhere near the same as being a programmer. If I am wrong about you, I apologize; you are the exception.

> To them, it sounds like you are asking them for a ton of money for better feng shui

I've used the analogy of kitchen / food hygiene. It doesn't necessarily improve the taste of the food but it prevents cockroaches and death by food-poisoning.

I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost multiplier" for every requested feature. So far, no one has the like the idea or phrase. I can't really blame them.

But there must be some quantity or term, with a nice memorable ring to it, that could get this across and at least let business people make decisions with full information at hand. Granted, any such numbers delivered in that guise would be wild guesses. But still, better than nothing.

Edit: However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully.

Your right, a large part of the problem is that there isn't a quantifiable way (outside of things like bugs/kloc, which are themselves suspicious) to identify a clean code base. I believe that is because much of it is personal preference, the same way some people find single family homes optimal while others like high rise condos. One person may think that adding some "clean python" code to an existing pile of bash scripts "cleans" it up while another may think that keeping the code base using a single language is cleaner while trying to minimize churn and bugs.

Bottom line, I frequently question much of what is being sold as developer productivity these days. It seems in my experience "this code is ugly/garbage/etc" is simply translation for "I don't understand much of this code". Engineers that truly understand the code base just go and fix it, usually with commits that are either small one or two line bug fixes with long commit messages describing how the system is failing and what is actually being fixed. Alternatively, they have "cleanup" patches that have extremely high removal/add line ratios which are replacing large chunks of difficult to understand code with small pieces that are easier to understand, and long commit messages detailing where the redundant functionality was. Very rarely are these changes to a different language/toolkit. But the evidence of skill in both these cases just about never include followup patches to "fix" new problems introduced by the previous round of fixes.

Benefits of oil change are also invisible until it’s too late, yet no one has problems understanding it. Can we learn something from that field, maybe? I’m grasping at straws here.

Definitely. Developing a unit of account is key to solving this problem. The problem was never that businesses didn't "get" technical debt, the problem is that they could only measure it by the volume of developers' whining.

If the business lacks sufficient capital reserves to continue operating through that customer churn then issues of clean infrastructure or good development practices become completely moot. The business will fail before the engineers have time to improve anything.

As long as hiring and technology decisions remain largely hype-driven, having someone around who says "we don't need k8s, hadoop, machine learning, and AWS with some big-ass Terraform-driven constellation of supporting serices for our expected data, workload, and use case; look, give me one middle-weight server, or one heavyish VM somewhere, and I can show you how to do all this with awk, sed, cron, and maybe a few lines of Perl or Python. We can have it up fast and anyone who can read man pages and a README can admin it, and anyway it's so simple and the workload static enough that once some initial kinks are worked out it'd probably run in a closet without issue for so long you'd forget it was in there—so, longer than this project is likely to be alive, anyway" isn't really something you want unless you plan to ignore them. For their fellow developers, that's résumé poison, you need "real world" experience with all this crap for the next job hunt. For the product manager, owner, and sales, you can't baffle stakeholders or investors or prospects with fancy bullshit when there isn't any fancy bullshit.

The article reads to me as "I didn't get my way and our code isn't perfect, therefore it's everyone's fault but mine and if only we'd embraced X, this would have all been avoided."

The author also equates "late nights" with hard work in point (2) which is a dangerous malpractice in itself.

Pretty dismissive take. The author presents a vision on how engineering can be more effective and protests against micro-management that gives them zero room for creativity and being able to put their best work.

Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well-defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.

> Languages that focus on "easy to write" are a trap

Reminds me of that time when my company abused Scala Implicits, possible because one of it's libraries for mapping scala to relational database had examples of it.

---

Regarding re-usability. Does that imply well defined interfaces and private scopes? Does that eventually lead us to Pure functions? Afaik, pure func has maybe the highest ease/simplicity for reuse. Happy to be hear your thoughts.

I think the idea is that low-interest rates cause investors to push companies to adopt riskier behavior and that easy credit enables said riskier behavior.

> You refactor your code as you go.

That's one of my most valuable self-taught truths! I fought with management and colleagues for years until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains both the desired feature (or fix) and the refactoring that slightly improves the status quo of the code.

This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.

while I agree with you, your description of refactoring scares me. It makes me imagine an over-engineered hot mess. I had a conversation with a junior engineer just today about valuing simplicity and avoiding abstractions until you're sure you really need them.

because cleanliness isn't really the goal, the goal is meeting business needs, stability, and discoverability. Often times abstractions create complexity, and that complexity hurts discoverability, it potentially hurts stability, and it can often times be detrimental if business needs change.

So I say abstract when it's clear that you need to, not before.

That's not to say I disagree with the sentiment to get the code working and then go back over it with an eye for cleaning it up, I just dislike the sentiment that this cleanup should be for abstracting things.

> Oh sure, you can solve the endless little meaningless problems that plague the day-to-day life of programmers everywhere, but the source of these problems — defects at the engineering level — are effectively untouchable. Also untouchable are the systemic issues that cause each of these should-be-trivial-to-fix problems into 5–8 hour tasks.

That part of #4 is so true it hurts. Most of the software I use is full of brokenness and "WTF"s.

About a year ago: AWS Lamba supports Java. Sweet, should be easy. Oh but the command line tools are broken in several ways you won't discover until you try, find they're broken, google around for a while trying to figure out what's wrong, then realize it's not your fault when you find the relevant unfixed issues.

About three years ago: Well I'm writing an Android app so this Google Maps feature should be a piece of cake, I mean, Google makes the OS so surely Maps is amazing on here. Except. Wait. No. That cannot be right. It can't. The Android maps SDK is missing features that the Javascript version has? No. That doesn't make any sense. Oh. Here's a GH repo someone already made to provide a convenient interface from Android Java to the Javascript maps SDK for this exact reason. I mean I guess I don't have to write it myself now but seriously, this was a fucking waste of half my day for no good reason.

A few days ago: Debian installer is flat-out incapable of writing Grub correctly. Several tries, every reasonable combo possible, boot fails with missing OS every time. This ain't my first damn rodeo—something's wrong. Think it's maybe a UEFI issue. Force UEFI. Now my video card doesn't work. Because it's not UEFI compatible? Why dafuq is that even a thing? Open case, reset bios so I have a display again, install again just to be safe, boot to installer's recovery mode, mount, chroot, install grub manually and in precisely the way I'd told the installer to do it the first time, and without changing a damn thing about the config the installer had just written, and it's fine.

This is basically how everything goes every time I try to do anything with software at all. Which is my job. So this is my life.

Software is terrible.

[EDIT] in fact I can think of one area where my tools are consistently as shitty, broken, and unsuitable for their intended purpose as software usually is: it's when I cheap out on power or (especially) hand tools to try to save a buck.