5 ms·
One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here. Doing stuff
by mkozlows 10y ago
One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here.
Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself.
This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.)
A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things.
(I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.)
In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.)
So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards.
It really does work, in a way that a dedication to cynicism never will.
- lotyrin 10y agoMaybe you're just not imagining the kinds of workplaces that we work in where we have these problems? There are teams where the political consensus is that even considering security risks is useless - who aren't budged on that position when after violating PCI DSS and having a database full of plaintext payment card information and also having a shitty copy-pasted-from-the-internet PHP newsletter form with an SQLi have payment card info stolen and used in fraud. "They probably won't sue" so even just fixing the SQLi wasn't important to them. There are teams where "SVN and Git are hard, so we just use Dreamweaver on the shared drive and use the built in file locking to make sure nobody steps on eachother's toes". There are teams where plaintext FTP deployment to production sites on plaintext WIFI is standard operating procedure. I couldn't convince them to change it even after showing them the username and password in Wireshark. "Anyone in the neighborhood could steal all of our client's data." wasn't scary. There are teams where leadership has no idea of technical realities, forms bad plans in the style of "We want to make Twitter, but for IoT thermostats" and gets to set the budget for those plans before even talking to a project manager or developer, and every initiative fails (doubly since they go over their nonsense budget, and have no nonsense customers buy into it) but it's fine because it's not like anyone will ever lose their job because they're 5 levels down from the CEO and five levels up from individual contributors in the software part of a hardware-focused fortune 500 so nobody in the C-suite understands or cares what they do and it's not consequential to the level where it shows up in shareholders reports. There are teams where they use a CMS + custom fields features and pretend it's an MVC framework and build line of business apps with only a few models but internal storage abstraction of the CMS and custom field feature blows that up into hundreds of tables with mutiple-tens-of-ways joins, and normal usage starts to DoS it and nobody can accept that they get to re-architect or even at least fucking throttle requests, it's just "fix it", who knows how.
- mkozlows 10y agoBad workplaces definitely exist. Sometimes, they can be changed, and there's a ton of scope for you to be the person who came in and got a dysfunctional department functional; sometimes, they're broken at a higher level than you can fix, and you just need to leave. But if you work at a bad workplace and your takeaway is "this industry is completely broken" and you turn into a full-bore cynic who refuses to believe that anything better is possible, you've gone badly astray.