As usual, the workers and managers are playing different games. As a developer, it's easy to assume that productivity is the game. Form a strong team and add business value through execution, right? Wrong.
Management is playing a game of consistency and control. Blanket policies are the name of the game. I don't care if you are 100x more productive at home. I can't have all these other losers asking me why they aren't allowed to work from home. God forbid I consider a stratified policy where some people get privileges that others don't.
This is why small companies move the needle on innovation, because they don't have to cater to lowest common denominator of 5000 people. Large companies are ruled by old men, and are beholden to status quo.
Wow. This really highlights the differences between a small company and a large company. I have a hard time justifying keeping B- employees on my team, I couldn't imagine calling people under me in the org chart "losers" without having an active plan to remove them.
Yeah, it's fairly gross. Insurance and banking are chock full of corporate cockroaches. They can hide for years without adding any real value. But boy, do they want their fair treatment.
I think the big dirty secret is that even in the office, there is a need for down time. The problem is that my options are limited, so I sit at my desk and look at the same stupid web sites in a clandestine manner. Or I get up and go for a walk, and try to get some fresh air. But my office building sits on an interstate and there are no walking paths or benches in sight.
At home, my breathers are more energizing, which is the point.
I can't believe how ridiculous it is that managers feign surprise when they are told that a task estimated at 4 hours will take a calendar day to complete. That is the nature of the work.
If I want to make a 2 hour task take an entire work day, I will do that whether I'm in the office or not. Sometimes devs need to coast a little. The notion that they will just continue to vigorously attach a backlog of monkey work is silly.
It's ok to treat adults with respect and empathy. Knowledge workers need more latitude to manage their pace.
I think when I was younger, I wanted to believe in it. But, yes, now that I'm older and I reflect, I don't think I've ever been part of one that wasn't fake.
There are the owners/middle management/laborers. To trick the laborers into thinking that they are part of something is pretty brilliant though.
I love the idea that we want to find the smartest people we can find, and hire them. Then tell them they need to drive in to an office every day and fill a seat, on the .01% chance that a client might drop in.
Yeah that makes way more sense than just saying, "hey a client is coming in on Thursday, everyone assume your positions! And for FSM's sake, look like you're collaborating!"
There's turds and turds. I've seen many of them and no two turds are alike:
1. A long time ago, we had this turd of a hardware abstraction layer that is every systems developer's nightmare. Windows drivers behind a middleware, with COM and whatnot. Support for USB devices, spanning back to Windows 98. No one dared touch it unless absolutely necessary. Fortunately, no one needed to touch it too often. The functionality it offered was rich enough that the trickier logic could be implemented at application level; it decreased code reuse to some degree, but then again, this was a critical enough piece of software that the time wasted by duplicating some logic among applications was offset by the testing effort required for changes in the HAL behemoth. Most of it was okay-ish, too; it crashed under a few circumstances, but not mysteriously -- we sort of knew where the bugs were, but workarounds were available and they were generally deemed good enough.
This was a reasonable kind of turd. I mean, yes, there was technical debt in it, Jesus, it had comments like "TODO: This looks ugly but for some reason it's the only way to make it work on <some Windows 2000 build>. Maybe figure out a cleaner way?", but it didn't really bother anyone. The code was architected so that technical debt piled up on separate shelves, too. The PCI (not -X. PCI. Plain PCI) stuff, in particular, was only touched by one or two people -- but it was perfectly possible to work on other pieces of that code without breaking the drivers for those weird PCI peripherals.
2. I was responsible for one of these turds. A while ago, we had to do a lot of fancy, detailed documentation for a custom logic design. This was going to be implemented in an FPGA which was going to sit in a pretty advanced medical device -- so you spec everything before writing a single line of code.
One of the things I wrote to help me was a tool that sucked in the timing diagrams in our docs (docs were in LaTeX, diagrams were in some markup language) and generated the Verilog code that put out those signals. This was a bunch of Python code, not too hairy, but it hardcoded every single assumption I could make. It started as a tool I'd made for myself; it was reluctantly promoted to a tool that everyone used.
Some folks tried to adopt it in other projects as well but honestly, the damn thing just wasn't up to it. I suggested to (my, by this time, former) colleagues that they'd probably be better off picking a standard markup language for the timing diagrams (maybe TDML?) and write something that was going to be useful forever, more or less from scratch. Or, if not, get a commercial, off-the-shelf thing that does exactly that, written by people who were paid to write exactly that. The time, people and resources for either of these options turned out to be pretty hard to secure, though, so they ended up polishing the half-bad Verilog code by hand. Still better than writing it all by hand, I suppose.
Frankly, this was at least an excusable turd. It was never meant to be used for so much. It got promoted from "a developer's hack" to "project infrastructure" through a combination of short-sightedness, lack of awareness of better options and bad communication, mine included. But it did provide some value and, honestly, removed none -- it sucked in the end, but it still sucked less than the other alternative that was actually available.
3. And then there's real turds. Like, there was this module I saw a while ago, as part of a bunch of firefighting meetings because the original developer had quit.
When it was initially written, it was rushed in, and the first thing that got crossed out from the list was IPv6 support. And fortunately for the schedule, it turned out some bits and pieces of another feature could be reused here and there.
The end result was a massive 30,000-line... thing, that not even its creator really understood by the time he was done. A good chunk of that code was there to glue the bits that could be "reused" to the new feature. There was no abstraction layer -- when IPv6 support had to be added in, what happened was another massive dump of maybe 10,000 lines, that was interleaved with the other one via a thick forest of if-this-is-ipv4-do-ipv4-stuff-else-do-ipv6-stuff.
After humongous amounts of testing and bugfixing, it actually made its way out through the door. which effectively marked it as "too expensive to rewrite", and that was it.
Unlike the thing at #1, there was no way to extend it, in any way. Adding even the tiniest feature took weeks and spawned dozens of bugs. Unlike the thing at #2, this wasn't some internal tool, it was production code.
Truth is, it works, or at least it worked the last time I had anything to do with it. But in terms of investment it was a really bad thing to do. It was so hard to extend that there was no way to accommodate customer requirements in any sort of realistic timeframe. Keeping up with the competition basically required two engineers working full-time, on something that wasn't necessarily a critical feature but you couldn't not have it.
This turd probably removed way more value than it added. Or, if not, it certainly prevented way more value from being added. It's my standard for turds.
Yes, that’s “value” in an important sense. But people rarely add in the opportunity cost.
We make decisions every week about what can be done based on the tech debt involved. Every time we punt on an improvement, that’s a real cost. These boondoggles that forever wall off parts of the product as immutable have a cost week after week. What’s the net value after you subtract that cost? Is there any?
I meant it more like a recollection than a lamentation, but it was cathartic here and there :-).
I don't know if it's obvious from it, so I'd rather spell it out -- there are times when "turds" are useful and not to be disdained, much like their real-word cousins: cow dung can be a good construction material and a useful fuel. Certainly worse than concrete and uranium but if that's all you can find or all you can afford, it sure beats eating raw meat and sleeping under the stars.
This isn't true of every piece of software shit in existence, though. Sometimes, "but it works" is just a bad excuse.
Yeah, I guess like most things that's true to a degree. But, those turds have a way of coming back to haunt a project in the form of technical debt.
It would really be interesting if you could calculate how much the technical debt ends up costing on the average project, and whether it's worth the savings gained from leaving the turds in place.
That's an excellent question. It depends, to some extent, on the question if a solution with less technical debt would've been possible at all.
Often, the "turds" were either the only thing possible at the time, or the savings there opened up other opportunities. Not always - sometimes the "cost savers" simply insist on digging a grave for the project.
But that's the main distinction - if it's bad and yet lives on, there has to be value in it. No company spends money on something that doesn't provide value. I suppose what you are arguing is that the product doesn't necessarily provide the maximum value possible. But that's a pretty high bar to meet.
There's always a "good enough". In a perfect world, engineering and product "good enough" coincide. If only one is good enough, you get either a badly engineered financial success, or a financially disastrous monument to engineering.
All other things being equal, only the former lives on. And hence, "turds live on" - and make money, and pay paychecks. And if their maintenance costs exceed their revenue, they usually get shut down.
(I'm deliberately ignoring all projects that can afford to ignore money. The rules are different there.)
Plenty of companies spend money on things that provide no value - which is why msrketing is a thing.
I’ve sometimes wondered - not entirely ironically - if development teams would be understood as a revenue source instead of a cost if they hired their own micro-marketing sub-team to do internal marketing to management.
my company has three pieces of software. one is an antiquated turd full of weird and incomprehensible design which, once you fully understand it, is even worse than you imagined. The other is modern as of a few years ago, and the third is modern as of next year and follows every possible best practice.
The antiquated turd is so profitable that it supports the entire company, the mostly-modern one is about at a break-even point of profitability after 6 years of development, and the modern one hasn't made a dollar yet.
What is the general opinion of CMM these days? I always associate it with UML diagrams for some reason. There was a time when the industry really wanted software to be fully specified. Seems like most people gave up on that dream, when agile came around and said "embrace change", along with the tenants.
But, alas, the pendulum swings. I think it's swinging back toward "I sure wish we didn't have to depend on finding skilled people, and our process was so bulletproof we could plug in any old schmuck and we can just continue to print money".
Interesting that you think SF is special because Google is there. What made it special before Google existed? What made it special before computers existed?
It's geography, climate, and culture make it special. Tech companies don't get to show up and stake an ownership claim on this stuff. If the hippies told the hipsters "we were here first!", they wouldn't be entirely wrong.
tech companies are not the only thing making SF special but they are the main reason behind raise in housing cost of recent decades and turning the area into even more exclusive than they were before.
If you profit off sick people, are you motivated to move toward a world with no sick people? If you profit from prisons, then you need to fill you prisons. Problem is, that as a society, we should aim toward not needing prisons at all. Therein lies the rub.
If I profit off of you being sick, then I need to keep you sick.
Normally that would be true, but under ACA profits are capped at 25% of premiums. They can increase profits only by increasing premiums, which can be justified by rising costs. Private insurance companies in America have no incentive to lower healthcare costs.
Well, that's true if they hit the cap and have no competition. If they don't have a 25% profit margin yet, they can still try to increase profits by cutting costs. There is also the strategy of lowering prices to increase market share.
The downside I was hinting at is that as a patient, cutting costs isn't always what you want. If it means more prevention or paying less, it's good. Otherwise it'll probably mean worse service.
I've been around long enough to see software development methodologies come and go. I worked for GE for a decade, and they tried to force Six Sigma on everyone. Devs put through training. Lean. KanBan. Single piece flow.
The thing that businesses don't want to hear is that software development is a skill game. You win by having better players. You cannot put blind process around every facet of it. I know you'd like to, so that you can then pay very little for unskilled labor. But the fact remains that you cannot, even today.
Wysiwig html editors and drag and drop UI builders for rapid application development were trending for a while in the 90's. Then everyone realized that giving these tools to monkeys resulted in a big pile of poo. So the trend reversed back to hand coding UI layouts using markup, separating business logic from display concerns, etc
I guess what I am trying to say is that if there is any hope in putting a lot of process rigor around software development, it will be enabled by tooling. Until then, skill and experience matter. And they aren't cheap.
Put another way, if the Cleveland Browns stole the New England Patriots playbook, they would still suck.
One interesting thing about software methodology that most people seem to like, such as testing and version control is that it prevents bad coders from screwing up a project too badly.
I also think that languages like Java have become popular in big enterprises filled with lots of coders because the language makes it hard to write difficult to maintain code by doing away with any features that would make it easy to obfuscate the intentions of code. This concern also had a big influence on the design of Go and all the features it left out.
The upshot of these coding methodologies that stood the test of time is that they protect the project from bad coders and they prevent really smart people from writing code that is too clever such that noone else can maintain it.
Instead the really smart people write abstraction upon abstraction until they can achieve the level of cleverness they wanted in the first place. I'm not sure all that extra code is really that much better.
> One interesting thing about software methodology that most people seem to like, such as testing and version control is that it prevents bad coders from screwing up a project too badly.
Effectively, these methodologies are a kind of bureaucracy. Besides self- propagation, the primary purpose of bureaucracy is to cover for incompetence. So testing and version control are (in part) a way to cover for incompetent coders.
Management is playing a game of consistency and control. Blanket policies are the name of the game. I don't care if you are 100x more productive at home. I can't have all these other losers asking me why they aren't allowed to work from home. God forbid I consider a stratified policy where some people get privileges that others don't.
This is why small companies move the needle on innovation, because they don't have to cater to lowest common denominator of 5000 people. Large companies are ruled by old men, and are beholden to status quo.