6 ms·
Somewhere along the way we forgot about software craftsmanship
- gjvc 3y agoAtlassian is responsible for putting the guns in the hands of incompetent micromanagers, for whom the likes are Jira are the wet dreams they can only fantasise about in their alternate reality.
- pcloadletter_ 3y agoAgile (TM)
- gjvc 3y ago* "the likes of", gah, sorry
- pjc50 3y agoProject management would be perfectly capable of being dysfunctional even when limited to typewritten memos. Jira is merely the place where the symptoms are collated. The lymph node of development.
- AnimalMuppet 3y agoYeah, but Jira lets them be dysfunctional much faster and more thoroughly, and with greater confidence. That does not improve the situation.
- proc0 3y ago> Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase. I've been trying to communicate this with absolutely no luck at all. Just coding is not considered "impact", meanwhile there are a ton of bugs and features take ridiculously long to complete. I believe this is major misunderstanding or lack of knowledge as to how software should work, thinking it's analogous to building hardware where you need more and more people to scale productivity.
- bazil376 3y agoIt drives me nuts. People cramming “features” into the app with reckless disregard. Moving through the codebase becomes akin to walking through quicksand.
- Tknl 3y agoHave you tried showing results of code qualify scanning tooling such as sonarqube or sonarcloud? This should show a downward pressure on quality.
- rogerthis 3y agoImpact should be measured as "features and their (monetary) value", not only "feature". Btw, I don't buy "long-term maintainability of the codebase". Ok, _I_ buy it, sometimes; my son doesn't. This above may be sad regarding the art side of things, but, well, it is what it is.
- CM30 3y agoYeah, this 100%. Which is why I suspect a 'winning' strategy for a career in software engineering is 'get involved in big new projects early on, take care of the low hanging fruit without much care for code quality or maintainability, and saunter off into the sunset before you have to deal with the consequences of your actions'. Meanwhile the folks stuck behind end up with the blame for these people's mistakes and the problems caused by their work, and get treated like poor performers because they can't just rush out features at the same lightning pace.
- tuan 3y ago> "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase A new feature = an increment in major version of your product, for example v1.0 -> v2.0 Bug fixing and other maintenance work = an increment in minor version, for example v1.0 - v1.1 No matter how many bug fixes or perf improvement you did, v1.999999 is always less than v2.0. It's a pretty sad fact.
- jocoda 3y ago0. We need this done yesterday. 1. Moving targets. As the code becomes usable it becomes clear what is really needed doing and how it should be done. And it's certainly not what was defined at the start of the project. 2. So the prototype/PoC works, thank you! - "job done" - more than good enough. No time to go refactor for the many little "todos" in the code that say " this code needs to be revisited because ..." as the next project "needed yesterday" is already here... Craftmanship is for academics and people that don't work in the real world because it needs time, lots of it.
- CharlieDigital 3y ago> Craftmanship is for academics and people that don't work in the real world because it needs time, lots of it. I think the biggest benefit of craftsmanship is actually flexibility. Well-crafted code has a property of malleability without becoming a tangled mess. Its parts tend to be more orthogonal and less coupled. I don't think that it's a binary choice of craftsmanship or shipping code; this may be true if you're a younger engineer. Mid- and senior- engineers can build well-crafted systems with less of a tradeoff for speed afforded by having more experience building and knowing where to add that malleability and where it would be wasted.
- bratbag 3y agoI've dedicated entire years over my multi-decade career prepping software for changes that never happen. Not once has a big change been correctly prepped for ahead of time. So my teams don't waste time on it any more.
- Doxin 3y agoIn my experience the best way to prepare for changes is to write dumb code.
- piva00 3y agoDumb code, easily revertible has been, by far, the most effective way to prepare for changes in my experience. Anything trying to be too smart, too generalised, too decoupled with plugable parts and it has a huge potential to become an entangled mess. While dumb code can be read and reasoned about quickly, if a change is easily revertible you can plug back the dumb code and try again without losing momentum.
- mvkel 3y agoIs this not simply because software is no longer art, but commerce? If you're making something for someone else, your soul isn't in it. So who cares?
- diatone 3y agoI’m not sure you can characterise all software with such a sweeping generalisation. There are plenty of use cases outside commerce - outside optimising distribution and trade of goods and services - which software contributes to immensely. Also, maybe there’s an ironic counterfactual in payment and financial reporting networks, like Visa and Peppol. Peppol is not for profit, and Visa infamously facilitates five-way transactions with a huge degree of backwards compatibility. As an aside, I wonder what code quality means to the author of TFA, and what craftsmanship looks like. Would be fantastic to get clear examples of this from the history of the industry.
- samarthr1 3y agoWho are the 5 parties in the transaction though? I can only think of 4 (acquiring bank, user bank, user, merchant), who is the 5th party?
- 082349872349872 3y agoIt was commerce in the old (late 20th century) days too, but releasing on tape/disk had its advantages: We shipped every year, or maybe every 6 months. What this meant in practice is that every team got their features to "shoddy" state, but one team would always take much longer to get there than the others, and because we were in a "feature freeze" near ship dates, the teams who were waiting for integration could use that time to clean up their features, applying craftsmanship to make things "shipshape"; products could ship with one or two wobbly new features, and most of them pretty solid. Now, with internet updates, as soon as a team gets to "shoddy", the feature ships; no one polishes; and all new features tend towards wobbly. (for the business this is an advantage, as features are stabilised only in response to demonstrated customer demand, but I think the enforced opportunities for cleanup on the old schedule, however disadvantageous for the business, were advantageous for engineering, as well as those customers who hadn't explicitly signed up for the beta program)
- VladimirGolovin 3y agoOn a wider scale, this is Scott Alexander's Moloch -- people who ship an Electron app now would outcompete people who would spend and 3x more on writing native clients for each platform in 3 different languages, and 3x as long to polish the codebase.
- flohofwoe 3y agoExactly. Electron is just evolution at work. The OS vendors had decades to fix their system UI frameworks and make it easier to write cross-platform UI applications. But they didn't because vendor lock-in was always more important to them, and that's how you get Electron. You reap what you sow ;) Electron has gone a bit overboard with the 'everything but the kitchen sink' philosophy, but the basic idea of a platform-independent application development framework is sound.
- rlawson 3y agoI'm investigating free pascal and Lazarus to see if viable multiplatform UI framework. Certainly much smaller binaries
- pjc50 3y agoNot sufficient craftsmanship to keep the site up under HN load, sadly.
- marginalia_nu 3y agoThe absence or presence of craftsmanship is primarily a differentiator in which sandboxes you get to play. You simply cannot build e.g. a viable dbms without at least a modicum of software craftsmanship. If you attempt such a thing with the shovelware mindset of most user-facing applications, it will simply never come together.
- crotchfire 3y agoOh it'll come together, and quite quickly too! Moments before eating all your data :P
- rocgf 3y agoAs with everything else, it's all about incentives. If well-crafted software made more money, then all we'd have would be craftsmanship. But it doesn't. There is plenty of software which has to be reliable and without surprises, and that is where you will find craftsmanship. Except that doesn't usually make as much money as "big tech", so it won't pay as much and that is the problem. People want to have their cake and eat it too - spend countless hours on problems that tickle their intellectual curiosity and sense of achievement, while also being paid handsomely.
- geon 3y agoI think quality does make more money, but there is no direct relationship. It is much easier to see the very direct relationship between quality and the expense, so that’s where the focus will be.
- pcloadletter_ 3y agoThis is my take as well. Quality is important, but at least in big tech, it's not what's going to get the quick win on the stock market. But when your product is falling apart within a few years, management won't have the faintest idea why. Must be bad engineers.
- rocgf 3y agoIf what you were saying was accurate and taken at face value, then we would see companies and products simply crumbling every few years, for seemingly unknown reasons. There is definitely some amount of truth to this but, by definition, it cannot be as bad as you portrey it.
- mrkeen 3y agoAgile (TM) is orthogonal here. If you have too much work, you have too much work. If anything, agile at least makes it possible to revisit parts of the software and fix them at anytime. No need to be in the same requirements/design/implement/test phase to work on something.
- j7ake 3y agoIt is also true that a clunky and inelegant piece of code that does its job is infinitely better than a pristinely written code that solves a slightly wrong problem. So iterating quickly and being agile is bad for the code quality, but it is probably good for finding exactly what is the right problem to solve.
- picadores 3y agoEvery project you goto, its allready a catastrophe. No tests, patchy expectations, strange visionary gurus with even stranger requirements, which of course change all the time and make no sense. No money for a rewrite, eternally add oriels to it. Frameworks, that are either old - but reliable, or new and ever changing. Wish, you could join companies and refuse to participate in old projects.
- crotchfire 3y agoGithub deserves a lot of the blame here. Teletubby-candy-crush blingware UI blended with manipulative social upvote features does not engender Göedel-level greatness.
- braza 3y ago> The last point I want to make is I feel like it's been forever since I had a conversation about craftsmanship on the job. It's possible I have just found myself in the wrong places time and time again. I can relate with the OP, not in terms of craftsmanship but criticality of things during the development process and operations. When I worked in finance (algo trading), I was amazed at how we had so many controls and guard rails we had to ship something, that during the time was almost impossible to go south because if we knew that if something went off our company would be burst more or less like Knight Capital. Fast forward to working in some SaaS, I always struggled to understand how things were so low impact/critical/important and how those things happened almost every second. Was hard to believe that some folks on the fund using VBA and excel spreadsheets were way more careful coding than allegedly professional software engineers. After some point in time, I just felt sloppy the whole process. With time comes maturity and you start to realize that each company has some kind of meta-culture around how things are done and you end up adapting yourself; but is not an easy process. Another thing that I noticed is that your early experience in SWE or experiences that you're operating in hyper critical industry or a world-class environment creates a massive imprinting that you carry along your entire career.
- black_13 3y ago[dead]
- deleted 3y ago[deleted]
- asimpletune 3y agoIt’s hard to fathom how much information technology is still in its infancy. Probably, one day, people will simply pay for software, and in that universe craftsmanship matters. Until then, the current conditions are largely collateral damage of adtech and SaSS. Still, it’ll pass. Software is just hard, and business is even harder. Eventually people who are good at both will win, but it takes time to sort itself out.
- bentobean 3y agoI serve as tech lead on a team of five people - each with wildly varying levels of experience. Those five people are spread out across two entirely separate projects. Tell me - how does one foster craftsmanship in that environment?
- wizerdrobe 3y agoDemonstrate it yourself in practice? I worked in such an environment and that’s how it’s done. Demonstrate it to your team, set expectations, have conversations about what matters. Encourage improved processes.
- JackMorgan 3y agoIt's extremely difficult to change a pre-existing culture. As the people turn over naturally, make extra effort to hire people who want to work that way. However, expect that they will clash with the existing team so try to bring them into the "craftsmenship conspiracy". Two good hires might change a team of five, and three definitely will. If your average engineer stays two years, that'll mean you're replacing 2.5 of them every year, so you could aim for that by 2025. Also, maybe start vocalizing and demonstrating what it is you want to see. Start a reading group around craftsmenship. Find ways to inspire them about how great it will be when you've got very few production defects or whatever it is that makes that team demoralized. As they say, "If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." The other thing is reward it. Not monetarily, but just reward effort that is improving the system. They will need time for these activities. When I manage my teams that develop long lived software I build in at least 33-50% of all time programming for technical debt repayment. There's no doubt in their minds that quality is extremely important. I'll also be extremely aggressive about abolishing deadlines. Unless there's a legitimate emergency, I'll assume all features are done when they are done. Also expect that they will find things to improve you never thought of or think is silly. Generally it's better to good people loose on technical debt than it is to be a dictator. With the right people, this is the fertilizer that lets them produce extremely high quality work at a good consistent pace, for decades.
- drewcoo 3y agoActual crafts, as in hand crafts are either wildly expensive or imported from the 3rd world. You can make them yourself, but then it's probably expensive not just in equipment but in time. With software craftsmanship, I think there are the same options. I don't think anyone forgot, so much as craftsmanship of all kinds got more expensive if you want it done here. And the money seems to matter to a lot of people more than ideal quality does. Far fewer people buy a (reasonably-priced if expensive) hand-made table from Amish craftsmen than buy (overpriced but cheap) Ikea garbage.
- deleted 3y ago[deleted]
- spiderxxxx 3y agoI always tell new developers, take pride in your work, and take the time to do it right, because your manager will not care at all about the quality, but it'll bite you in the ass if you don't. The only person who is going to care about craftsmanship of your code is you.
- SteveHammans 3y ago[dead]
- wduquette 3y agoAccording to my job title I'm a software engineer; but I've always regarded myself as a craftsman, writing bespoke handcrafted software. I am also (as the OP suggests) a few years from retirement.
- ssss11 3y agoScrum feature factories