Software Craftsmanship vs Software Engineering
ฝัง
- เผยแพร่เมื่อ 18 ก.ย. 2024
- Software craftsmanship was an important step forward in software development, but it doesn’t take us far enough. Software engineering has a poor history of often being characterised by bloated, overly bureaucratic approaches that got in the way of good software development, rather than helped it, but engineering has to be the goal, because engineering is "the stuff that works”. So let’s look at software craft vs software engineering, which is the better approach and why.
In this episode, Dave Farley, author of best sellers "Continuous Delivery" and “Modern Software Engineering” explores the nature of software craft, and how engineering allows us to enhance it and take it further.
-------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! If you join by the end of October, you will be entered into a book giveaway to get a free copy of Dave's latest book "Modern Software Engineering", or even a signed copy of one of Dave's books.
JOIN HERE ➡️ bit.ly/Continu...
-------------------------------------------------------------------------------------
🔗 LINKS:
📄 Martin Fowler’s Description of Tech Debt: ➡️ martinfowler.c...
📄 Wikipedia’s Description: ➡️ en.wikipedia.o...
📄 The 1960’s Software Crisis ➡️ en.wikipedia.o...
📄 The NATO SW Engineering Conferences ➡️ homepages.cs.nc...
📄 Software Craftsmanship - Wikipedia ➡️ en.wikipedia.o...
📄 SW Craft Manifesto ➡️ manifesto.softw...
📄 No-one killed in commercial aviation in 2017 ➡️ www.reuters.co...
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribep...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) (Robert C. Martin Series) ➡️ amzn.to/3aLXGad
📖 The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition ➡️ amzn.to/3EdXvBm
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ oc.to/Dave-Farley
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.or...
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
My wife told me after she had to do some programming herself: "Ain't this art? It sure feels like it."
And I would say: "Yeah. Somehow. Some parts."
When she hears me speaking to colleagues about architecture and plans and organizing things: "Look at those silly diagrams. They almost look like blueprints."
When I tell her about how we roll out changes or do experiments: "But that's research, isn't it?"
That's what I love about our field. There's so much to it. It's like crafting nice furniture while at the same time experimenting how to improve the crafting process and durability, what wood works best, what customers like best, and building and maintaining a distribution pipeline. And all these simultaneously. While your boss is asking you too attach the third USB-powered, ice cooled beer holder to the kitchen chair, that tweets everytime you put down your bottle.
But let's not forget that craftsmen may do this as well, just at a different pace, I guess. :)
I am both a Software Engineer and a programmer (craftsman). The skill sets required are different. I have worked with a lot of very good software engineers who were not able to write well crafted code. Conversely, I have worked with excellent programmers who write well crafted code, but aren't engineers - they can't design systems of programs or solve complex problems by decomposition.
The problem is when an organization doesn't distinguish between the two and expects everyone in the software department with equivalent years of experience to be interchangeable.
The industry needs both.
Daniel everyone his own approach but as you told in the software department they look for experience and not for the title. Which Dave try to emphasise is the approach of the engineering. Digging more in problems iterate and look for quality. I am too a software engineer and I was fascinated by the craftsmanship approach but I really find myself and my thought in this video
I like your thoughts, thank you for sharing them. I think a software engineer must be able to 'craft' at least to some degree.
Well said. In software, we're used to wearing different hats. Just as our discipline is difficult to put into a box, so are the problems we're expected to solve with software. I generally think of myself as a problem-solver, more than a Software Engineer or craftsman. However, between the two labels, I am always called upon to think creatively (craft), and often called upon to think scientifically (Engineering). At the end of the day, these labels don't change anything about how I go about solving problems. I use every tool in my toolbox, wherever and whenever they are needed. As long as the product I produce helps the customer, I feel I have done my job.
I feel like you have said what I wanted to say in a concise manner. As a mechanical engineer, I see myself as a software "designer" (borrowed from mechanical designer). I use existing tools to write programs using existing patterns etc to assist in my engineering role. They are unique pieces of software, but the systems are not new. The engineering I'm doing though, well that's constantly bumping up with the limits of nature, and then pushed further.
Respectful... well, not disagreement, but a counter-point.
I trained as an Industrial Engineer (picking up an Accounting minor in the process) and then Software Engineer (picking up a math minor in the process). I humbly admit I was never professionally certified as an IE (80s and the rust-belt made software pay more), but I have done well in the software industry, and like the author, I've been around the industry a bit.
So I introduce a third paradigm to this debate, one not set in Engineering or in Crafting. Software Design and construction is more akin to Laboratory Research than engineering or crafting.
Crafting involves skilled and well understood tool use, whether it is a carpenter utilizing a planar for leveling a door or a code utilizing a debugger to understand a subtle error in logic in their code. However the problems are well known, and most of the solutions too. Engineering is the application of mathematic model shown useful over history that they can be applied as general solutions. The problems are more unique, but the repertoire of solutions that can be applied is well known.
But research is a continuous loop of hypothesis-test-measure-repeat. You eliminate all superfluous factors, reducing your test to just test the smallest unit you are targeting.
I think perhaps that is the model of development we are all doing. The hypothesis is less a general "does this work?" but a more specific, even miniscule, item such as "does this method do exactly what I wan to do?". Toss in the uncertainties of the libraries you use (which may not work as documented) and you must engage in a paradigm that, to me, much more resembles laboratory research. This also fits your Continuous Delivery concept, which itself can be compared to a slimmed down for software version of laboratory science.
I am, of course, open to debate on this.
This is all about metaphors...
Thing like that are completely open and depend on the viewpoint.
I think that the best analogy to other established disciplines for software development is that of architecture. Architecture has science and engineering involved in structural engineering, material characteristics, air flow considerations and such things that can be measured and optimized in a calculated fashion. However, there are also aesthetic and subjective considerations of beauty and ease of use and livability. Software is similar in that usability can be as critical as efficiency. And because of the abstract nature of software design, even aesthetics of the design (e.g., simplicity and elegance) can be measures of excellence. An imperfect analogy can be made also in the fact that architectural teams utilize structural engineers as well as designers. Software is often developed by both the back end developers (more engineering and efficiency oriented) as well as front end developers who are more concerned about aesthetics. It's all an imperfect analogy since software is fairly unique in its wide applicability. But the analogy can be useful at times.
I'm definitely an engineer. I also think we need to include readability when we talk about quality metrics, defining readability in objective measures
I was fascinated by how, after your discussion about how software is not a physical product, all of your design examples were physical products. My hesitation at the title of engineer is solely in deference to real engineers because I don't have an engineering degree. It also struck me that the things you mentioned regarding software design are also true of writing. They are both all about organizing information. Thanks for your thoughts.
Engineer and Engineering degree are two-three very different thing; people who do engineering, people who are held to an engineering standard / field certification, people who have academic engineering degree. These are different things in all fields, certainly not unique distinction to software.
There are several people leaving computer science degrees who are just good at barely passing courses and choosing the easiest courses who will never be able to provide any value to an engineering / building / crafting / … job. And you have people who are amazing. So the academic degree is just one indicator of a persons abilities.
In Canada, you cant use the title "Engineer" if you are not a registred engineer. Microsoft had a "Microsoft Certified Engineer" training and were condamned and obligated by law to change the title. The whole idea is to protect the public: engineering is a reserved act, reserved to engineers.
On the other hand, software engineering is a grey area since graduates in Computer Science baccalaureate end up doing the same task as trained software engineer.
@@EtienneSavardz Thanks for the info! I have a BA in English so there is no gray area for me. :)
@@randomgeocacher in most colleges, computer science is taught by the engineering department, and includes most of the generic engineering discipline classes that other disciplines use. Most colleges also offer degrees in software engineering and computer engineering (kinda an electrical/software hybrid degree). That said in industry no businesses care which of the three you have unless they are designing chips in which case they either want electrical engineers or computer engineers. Computer science was meant to be more of an academic degree kinda like physicist vs a mechanical engineer but the curricula are too similar in the real world
Fantastic video. One of your best. A tour of history, philosophy, and practicality.
Got your book last night 🙌 Can't wait to dig in this morning for some inspiration before work.
Thanks 😎
I sometimes jokingly refer to myself as a software practitioner (due to my specialisation having a subtitle of "software practice") but the parallels can be quite striking (we diagnose our "patient's" issues, then try to prescribe the best solution. Any mistake we make could be lethal or severely impact someone's life). In the end if you abstract enough away, anything can look like anything, so the best solution is to find a name everyone can somewhat agree on and move on.
I would say it is a healthy mix of both for me. I like to "craft" software, to see the outcome I produced, but I also try to engineer it, design the architecture of the classes, think about what technology I use and why. I think it is a very important skill even I am not working in a position where every choice I make is important for the whole organization. Sadly, I think more than enough programmers don't try to make a design and although they are in a position where they have to design something from scratch, they just try to use the "well but it works" solution.
Dave - I appreciate your thought-provoking videos.
I think anyone and everyone should be able to code - to be a craftsperson. Coding is a medium with unlimited possibilities.
That said, I don't want just anyone writing the software for airplanes or even huge and important sites like TH-cam. That should have controls and regulation around it. It's a matter of scale, real-world consequence, and discipline - that's what I'd call "engineering."
But I do believe that "craftspeople" are a necessary precursor to "engineers." I think crafting is a zero-to-one pursuit, and engineering is everything beyond that. They are both hard in their own way.
Listening to this a definition formed in my mind "Crafting is the process/tool to realize the engineered solution!" Looking at software developing from this point of view a junior software developer is a craftsman. A developer who is not a junior any more and have a couple of years experience is also a craftsman. When a craftsman has enough experience and knowledge to design systems and use these to design systems he/she becomes a software engineer.
i would say it does not matter
I believe engineering has a component of craftmanship and art. Looking in the dictionary we can find: Engineering = the action of working artfully to bring something about. Artful=clever or skilful, especially in a crafty or cunning way.
Craft implies close work, done at the moment, without a larger picture in mind. Engineering, on the other hand, implies something more academic in nature, based on principles, and expansive in origin. Engineering is in the abstract, craft in is the concrete, and while both can make better products, engineering seems to be an essential element. I think some aspects of software development are engineering and some are craft-like. Craft reminds me of squaring the edges of a product, of something aesthetic, like refining the UI, or structuring code for usability (for other developers). Craft also implies practical experience, an understanding of aspects that might not turn up in an academic text, or the result of a study.
Accidentally bought two copies of your book David… have a gift for someone. 😊
I don't think that true "engineering" in software really exists right now.
Would you call an artist an "engineer"? No. Simply because you can't just crunch some numbers, lookup a datasheet table, and get some painting or poem as an output. The same goes for software developers. It isn't that extreme like aforementioned art, but it is somewhere on the spectrum between art and engineering.
As for craftsmanship I understand this term as combining some form of art with some engineering. It is hard to pin point where it is exactly on that spectrum, but I would say software development lays somewhere around this region, with some bias towards engineering.
Of course very low level stuff, like for example mentioned Apollo program, could very well be called engineering. But it is only possible at very low level. For most development we are writing at so high level of abstraction it moves us more towards craftsmanship and art, and away from hard engineering. We have some rules, "datasheets" and best practices. But not in the sense of engineering. We can follow them as much as we can, but it does not guarantee success. We need some art, and that is not quantifiable.
My wife and I have been in disagreement on this subject but you may have convinced me to join her side haha.
I do see strong similarities with software design and various engineering fields. Electrical engineering would be my guess as the closest relative to software engineering which is similarly design focused rather than production focused.
My main hesitation with claiming the software engineer title over software developer, is the lack of a licensing requirement. It's something that I hope regulators will bring about in the future and in that case I'd fully agree!
That is an interesting subject, and question, I want to say that what I'm doing it craftsmanship. But that doesn't mean that I reject the engineering approach. To me craft is about something that I live for. As for defining craft in software and what it is, that is an different matter.
As a mechanical engineer, I feel like the argument fits better under "design". The use of existing knowledge packaged differently.
John Carmack with Doom would be an example of software engineering for me. Shifting bits in regards because it's quicker than doing the maths through the CPU etc. It's taking the knowledge of a system and abusing it. Finding a way past the limit, not by going through, but by going around, to reach the limits from all sides.
I have done a lot of work were I've been a mechanical designer. It's interesting, it's still challenging, but it's been done before, all is be doing is adjusting to meet the new size, to fit the new geometry etc.
With how you push things and the influence you have had in the industry, if argue you are a software engineer. That does not mean all are. There is place to be a designer, and honestly it's less stressful and can be just as fulfilling as the problems and challenges vary so much.
First, I emphatically support that you brought up Margaret Hamilton. We software engineers owe our entire livelihood to her. Very under-celebrated for how influential she was.
To me, when I think about the "craft" of software it has more to do with the bespoke and under-specified creative aspect of it, then some kind of counterpoint to engineering.
Software is interesting because it is not restricted to the laws of physics, it's only restricted by the limits of human thought (and undecidability) which is far more vast then physics, and for which there is no universally agreed upon laws.
With traditional engineering (let's take Civil Engineering; building a bridge) there are well-defined requirements and parameters that guide the design and building of the bridge. Civil Engineers are expected to know and evaluate these by using laws of physics (and derivatives thereof) and matching that against the economics of the project; we don't ever engineer the scientifically perfect bridge, we do the one that is most effective given the physical and economic requirements. There is certainly some bespoke and creative aspects to building a bridge (they all don't look identical after all) but we tend to use the word "engineering" to describe the more scientific aspects of evaluating requirements against tolerances and well-understood models.
With software, it's more like bespoke art and that is where the idea of "craftsmanship" comes in for me. Let's take pottery as an analogue, If we were mass producing ceramic mugs, we could (and do) automate that. And in that case all the mugs are essentially identical, no craftsmanship (I would argue). In the analogous software world this reminds me of all the No Code stuff you talked about a couple videos ago. The point at which we need us software engineers, there is a bespoke requirement with no completely-defined solution and it requires the creative hand-touch. To me, that evokes the word "craftsmanship."
Having said all that, the comment about how the "engineering" in software engineering has to do with scientifically evaluating and refining the efficiency and effectiveness of our creative endeavor is thought-provoking. This is some kind of step above what I think of as craftsmanship. My dad is a craftsman wood worker... when he builds something, it's often over-built, he takes way to long to build it, and it emphasizes aesthetic elements over functional ones. I'm quite certain he is not going back over his woodworking accomplishments and scientifically evaluating and refining his approach and thus I would ascribe the word "craftsman."
Personally I think this is more about professionalism. A professional is someone that is responsible for constantly evaluating and refining their approach. A scientific method happens to be the most effective approach to do this. Although with software engineering, its really about the interaction between other humans (our fellow software engineers), the science is squishy and imperfect. For example, we can't quite be as precise about the application of XP vs. Waterfall or Java vs. Kotlin as we could be with steel vs. aluminum. So I might even challenge that "science" is what is going on here (Margaret, if you're out there, I would love to hear what you have to say). However, I think anyone that does social and decision sciences or economics would beg to differ, and I think that's very valid.
Clearly I'm still thinking this through... although I'm worried it's a bit of semantic tug-o-war. For now, it actually seems to me that software engineers are doing all three:
Engineering - Building the right solution that is needed and ideally no more (e.g., not the scientifically perfect bridge).
Craftsmanship - Building bespoke solutions given incomplete requirements and understanding (e.g., the one-of-a-kind mug for very special customer).
Professionalism - Obligated to continuously practice, evaluate, grow, and sharpen their skills, and to be the responsible software expert.
(Maybe also science)
I like your explanations. I use kind of same physical silly abbreviation how a car or a house is built.
But most of the time even no-it-ppl understand certain cases better this way.
So I see me as Engineer, Architect, Craftsman or Developer. For others I'm the IT(Computer)-Dude or Lifesaver.
Whatever title I get, building Software or Hardware is fascinating and fun for me.
This video turned out to be quite an eye opener for me. As someone with "just" the title of "Software Developer", I've been wondering for years whether I should go after the arguably more distinguished title of "Software Engineer".
The way I see it now is that my current title implies that it's my job to create or add value. Which in my book requires both engineering and craftsmanship. And I really don't understand how designing things in an ivory tower without implementing anything could ever work.
I think the feedback loop between design and implementation is extremely important. Because that's how we learn.
I will happily continue "just" developing. Thanks Dave, for another great video!
I have considered myself a "Software Developer" for the vast majority of my career. Now I think we should start to make this more of an engineering discipline, let's agree one what we mean when we say "This SW is good" so that we can rule out the bad, that is really why I care about the distinction. I think in employment and industry terms "programmer", "developer" and "engineer" are used as synonyms. It depends on the employers how they describe the job, but you get "engineers" who practice no engineering, and "programmers" or "devs" who do real engineering work. This is part of the problem, we don't have definitions that stick.
@@ContinuousDelivery You are absolutely right, and I'm probably confusing titles or roles assigned by the industry with what we already know to be true. Because it is confusing. We all should think and act like engineers while doing our work. Especially when in a position to make mission-critical choices with long-term consequences.
Somehow I associate the term "Craftsmanship" with the OOP mindset, to which I also associate a lot of things like the Agile manifesto and the rationale of the "purist" TDD, Architectural Patterns and so on... something more owed to the way our software practices ended up developing to the present times.
I recommend Glenn Vanderburg's "Real Software Engineering" talk. There are a few different versions online; I watched the 2012 InfoQ version but see there is a version from 2019 which is probably more refined.
It’s really a bit of semantics, though, isn’t it?
I mean I agree with all of the points made in the video. I just don’t really think these labels have done anyone any good.
I'm a Software Craftsman Engineer.
I've not understood at all where the two approaches are mutual exclusive...
In fact I see no point in comparing them, oppose them, or trying to say that one is better than another.
This reminds of the “SRE implements DevOps”, like an Engineer implements Craftsmanship?
Maybe that would work. An Engineer should understand the craft but how it’s implemented could also be done by a specialist of that craft. Having worked in HPC environments and cloud development, there’s craft required within those specific domains, an Engineer should understand the domain enough to understand the design constraints and be able communicate the requirements to a craftsman that then implements them within their domain expertise. That person could be one and the same, or a team handing off to another team.
Anyways thank you for your content Dave always thought provoking.
last bit was dramatic 👏👏👏
Deliberately reducing value happens all the time in software world (sometimes at design stage, sometimes after initial release) mostly for commercial reasons. I'm not talking about time bombs placed in software to justify maintenance contracts (tha happens too... but most would classify that as criminal acts). Sometimes, within the boundaries of laws, software is added so that a program becomes less useful. There are entire industries about just that. We as coders quite often are not adding value for who pays... we actively remove value for who doesn't. Frequently even as an afterthought by the commercial side. It's even illegal for the end users remove those artificial limitations by themselves.
The issue is that, with software, we have moved far beyond "provably correct". Back in the day, I did some CAM stuff so had contact with mechanical engineering. If you want to make a part conforming whichever ISO/AQAP/Whatever standard, you have to be able to trace everything. The raw material has to arrive with a certificate saying it's the correct material (and there are a lot of alloys), the processes and inspection have to be documented.
Software, well now you're relying on 3rd party libraries, you're relying on 3rd party runtime environments (containers, OSes, whatever). You have little control over what else is executing on the machine at the same time that might make your life difficult. All you can do is test. With software projects, you could be dealing with as many moving parts as an airliner, but without the time and budget that goes into the development of an airliner. Interesting that the 737 MAX 8 problem was in the software.
That's not to say that the industry is hopeless. There are some things. FMEA (Failure Mode and Effect Analysis) can be done and works well. It's the "how can this fail, how does the failure manifest, what needs to happen to fix it" type of thought.
I think both labels have baggage -- pretty soon we're all arguing about who the real Scotsman is.
Engineers can get into legal issues not in case of catastrophic failures, but only if they didn't follow the established rules. If the bridge you designed falls and kills a thousand people there will be no consequences if you can prove you followed the rules. On the other hand there can be legal consequences if you didn't follow them, even if the bridge works perfectly.
Yes, true. Imagine if that was true for software, if something bad happened your SW was modular, cohesive, has good-separation of concerns, loosely-coupled and had good lines of abstraction - and you knew it worked because it was tested, then "not your fault", if it missed any of those, then "Why weren't you doing a professional job?". 🤔
@@ContinuousDelivery I think software (the coding part, not system deployment) is substantially different from many other disciplines because it has no replication cost and no replication problems. Making one millions exact copies of the same car is difficult and expensive, while downloading the same program to millions of PC costs pennies and is trivial and perfect... no surprise that by marketing them like there was a per-unit cost made bill gates that rich. The main problem with software engineering rules is that IMO they were designed with the "real world" in (the back of) the mind, but 1) writing programs is just about making "prototypes"... mass-production (a lot of what engineering is about) is an incredibly easier problem in software 2) we tend to lay out rules about how to write good software when indeed it's still not 100% clear what works and what doesn't... a lot of those rules seem to me like codifying and making laws about medieval medicine (we don't really know yet). What are the proven methodologies in the real world about making good prototypes and having good new ideas?
@@AndreaGriffini Your maintenance costs will scale proportionally to the number of users (customer support, adding new features, patching security holes, etc) so it's not completely fair to say there's no per-unit cost.
@@tourdesource If you sell some substantial and expensive service too that's true. That's a big IF.
Great water cooler discussion. The key as I see it is that great software implementation is an art. The conditions and constraints might not be. They can come from engineering or from business or regulation. But the implementation will be crafted and built by software designers which ultimately always works in part as artists. If you let a solution out in the wild and it's purely engineering driven you end up with black holes Like Kubernetes. It's a great technology but it's like a bridge. It has already been built and one day it will be decommissioned because it's replaced by something new and better. The engineering approach will not lend itself well to innovation. Any product that is in "stable support mode" before it's decommissioned.
I think the setup is wrong. Its not question really about craftamanship vs engineering. Its about context. If you have to deliver business that customers need that more business orietend than technical, its craftamanship. Because you have to handle customer needs beside the code. If you can just concrentate in code lets say C system that directs robots, its engineering.
Different is that first approach needs heavily people who concentarte also to social skills and business. While latter is just engineerin work. Craftamanship comes understanding the context that is needed to deliver solutions for people. Its engineering when you solve solely technvial problebles. First one does not have education or rules that apply every situation. Latter can be standardized technically.
For me craftsmanship is synonymous to a commitment to excellence and continuous improvement. Whether a developer calls themself an engineer or otherwise is a question of symantics in my opinion. The title you choose has no influence on the code you write.
I don't mean this in terms of titles, I mean it in terms of approach. I'd disagree that "Craft" is synonymous with quality. Craft is variable and unpredictable. To do better, you need creativity & skill, as with craft, but you also need a more disciplined approach to problem solving.
@@ContinuousDelivery I am with you. I am just expressing perspective. A craftsman in woodworking for example communicates a level of experience and skill. For me, craftsmanship conveys the intention to achieve that. It means different things to different people, depending upon perspective. Keep on with your videos, great stuff and I share them often with the engineering managers (can you see where I am going here?)
I am trained as a mechanical engineer, but my main field of work is writing code. So I have a preference towards the Ide of Software Engineering. In Designer Engineering we have a whole field of research devoted to steering design processes. I found these Ideas th be of much value to developing software, when taken with a grain of salt.
For example in risk evaluation or the design of meaningful experiments design engineering has a lot to offer. However, I have also experienced the burocratic nightmare when working with organizations which are rooted in mechanical engineering.
I think this stems from the idea that product changes are always expensive due to production and have to be avoided by getting stuff right the first time.
TLDR: Software Development can learn from engineering how to conduct meaningful experiments, but should avoid the mindset, that experiments are very expensive.
This is such a thought provoking video
I would like to be more of a Software Engineer. Nevertheless, I'm a craftsman too often, more often that I would like to. In the business world, there are long-term strategies and short-term tactics. Some companies sacrifice long-term positive outcomes and quality for short-term "evading maneuvers" to win with the current market, competition, and investors. It is like we win the battle and put down current fire but at the same time, we make winning long-term less likely. But the current battle matters - if we lose it, we might as well lose the project. I'm not really sure what should professional small subcontractor do in this situation. Agree on making something worse but working on a too small a budget and time - so the project will go further but suffer long term? Do not agree and risk making startup project fall and client loose money? Maybe it should fall if it's not planned nor budgeted well and sooner is better (like a stop loss)? On the other hand many well known services started as such quickly and dirty projects.
Is the production cost really zero?
I think, while its free to copy the source code, actuay running an it system is not free. You need servers, maybe in a cloud environment. You need people to configure and monitor the software. And things like scalability does matter. So we have our own production challenges.
My thoughts exactly. Software is not a disembodied entity.
While "production cost" is technically correct, it is misleading due to the various meanings of "production" in English. Software has a near-zero "marginal", "replication", or "duplication" cost. In other words: we have trivial copy and paste, unlike anyone dealing with physical media such as bricks and mortar.
While coding itself does have elements of design in the broad sense, it is not "the design" of the system. The design is the set of patterns that together describe the system, including algorithmic, physical, logical, UI, and behavioral. Coding is craft (imagine a sculptor), not engineering. System- and software- and algorithm- design, are engineering. As a developer designing an algorithm you might play with code in the way a bridge engineer might toy with scale models for a bridge; but this does not mean that making a model bridge out of cardboard, or coding, are engineering. The distinction remains.
For a complicated set of reasons including economic expediency, in most software projects there is a complete absence of a distinction between design (drawing the statue, considering its center of mass, weight, and size of plinth) and coding (sculpting). This conflation causes important problems.
"Once we have a design, press a button and bingo we have a sequence of bytes that represent our system." No. A design is only the initial step. It might be only the first design of many. It might be a napkin sketch. It might be implicit because that's how the organisation has implemented similar systems before. But the design - the engineering - only prepares you to start the craftsmanship. So we start with a badly-/well- engineered design and then use craft to carve the product out of the technology and media we have decided to use. Note that the design evolves and may change tomorrow, or next week, or next month. The meme that, with an agreed design you can hire ten devs to "push buttons and bingo, we have a system!", devalues the craft of coding and is a primary cause of project failure. There is plenty that can (and usually does) go wrong between having the (usually poor) design and delivering working software. BOTH the engineering and the craft are important pre-requisites for a successful outcome.
"Pushing the button" only triggers the automated compiler and "build" (a misnomer, really) pipeline, akin to a post-processing step (imagine putting a clay pot into a kiln). Very important, but it requires the construction of the system (craftsmanship) based on a design (engineering), to have occurred first.
I think putting a label on it is largely pointless. You need to be able to think about the problem and design a good solution, and you need to be able to get that solution from your head into code. The important part is focusing on the things that make software better e.g. loose coupling, easy to change etc. Call me a "software person" for all I care.
If I had to pick one, engineering covers more of what we need to be able to do in order to write good software.
Great points! Little by little, you might just mature our field.
Personally, i think that the interest in making software production more a craftsmanship instead of engineering is a decision based on finances and corporate culture.
Engineers are expensive and intellectually intimidating, even when they're humble. Good ones are hard to find and even harder to replace. Companies prefer to have many replaceable developers instead of a few critical engineers. As long as they're not killing anyone, they can deal with releasing buggy code and patching it up after. They rather deal with chaotic delivers and spaghetti code rather than to deal with those intellectuals.
Plus, if they can get enough people to join the software field, they can lower the salaries. That's the main reason big companies are desperate to get everybody into coding. That's the reason big companies invests lots of money in tools to make software development more palatable to the average person.
To me, what you call 'software engineering' is what I think of as 'professional software engineering' - it's commitment and results driven
I don't really like any terms. Craft makes us think that we are producing things. A well crafted chair is finished, we won't ever change it in it's lifetime. In fact a well crafted chair begin its life when produced and being actively used by people.
In my mind, software is a learning path. As long as there are people following the learning path, the software still lives. When no-one follow this learning path anymore it means that the software is not actively maintained and so it is by definition a dead project. It can still be used, but experience shows that not actively maintained software just die really really fast.
I don't like engineering because it let us think that there are rules that applies in every project. It works in some industries because for example the laws of physics are always true. That's very mathematic and cartesian. We don't have that in software. We start having some techniques that seem to have better results but they are just heuristics (like devops, agility... etc). And no-one agrees on how we should apply that in our projects.
Software is different from each company and from each problem. In fact even software that aim to solve exactly the same problem don't look alike: they represent a learning path. Learning path are differents because people don't learn the same way from each other. We are more close to soft science than hard science. Hard science is simple, there is a law, we just need to apply and the problem is solved. Software have to compose this with human interactions leading to pretty unreproductible situations. And that's what makes software development interesting in my mind: finding the right solution to the right situation.
So how should we call ourselves? I don't really care as long as you don't think of me as someone that just produces something.
My favorite quote is "Software development is a learning process, code produced is just a side effect". So if I had to choose, I would call me a "continuous learner".
I was wrong. We are wrong. Engineering carries with it a code of conduct. We iterate with objectivity in our evaluation of success. Have we met the requirements? As an engineer in transferring the architectural design to the same picture written in clean and readable code . Our applications are no more than a catalogue of need, requirement, expected outcome. We are objective in our evaluation of success and failure. A craftsman protects what they have done. the functionality. We dear commentor are Engineers.
A big problem is when software developers never educate themselves as engineers. Then if a software system has any of these developers working on it, it will never be possible to sustain good engineering practices in it: these developers will fail to know how to maintain those practices.
Waiting for the independent pop-up farmers' market community software _artisan._
🤣🤣Me too, with homeopathic continuous delivery.
Like you aluded to in your video, maybe we should use neither term and opt for "Software *Designer*" instead.
What do you think?
I think that this is about more than the label. I think that what we should do is to train, and practice at being "Engineers", adopting a more scientific inspired approach to solving problems better. When teams do this, they get a lot better results.
@@ContinuousDelivery I have to agree with you there!
The Engineering aspect really boils down to functionality and testing of the product. It assumes a clear product goal/requirement.
The craftsman is more about discovery, trying/failing, and piecing together something useful resulting from that discovery. It is what most open source code is about. Ironically, code quality is often better because of the attention paid to the code itself rather than its edge cases. As a result, many people are able to collaborate on the code easily but it is still littered with bugs.
I disagree. SpaceX are currently building a rocket that is to go to Mars, this is certainly "Engineering" the goal may be clear in general terms "Let's go to Mars" but the that is a bit like Amazon saying "Let's sell books on the Internet". Design engineering is *all* about exploration and discovery.
I think that you are falling into the trap of confusing "production engineering" which is not our problem, with "engineering" which, I think, is.
@@ContinuousDelivery the rocket has very specific goals however. Needs to reach Mars. Needs to be able to land and relaunch.
A craft is something you would piece together in the backyard and it would really just be a prototype. The real rocket has to be engineered and tested very thoroughly to be approved for use.
Oh yes, programmers are famously good at naming things, so let them decide how they should name their discipline.
I think it is about a lot more than “naming”.
x
engineers are covered in soot and deliver things that “need to be knocked in the right way” to get working but work. they work fast and hard it’s rare they get the luxury of time to drift into craftsmanship
No they aren't. I have met Anita Sengupta a couple of times, she designed the supersonic parachute system that allowed the Curiosity Rover to land on Mars, she is an Engineer. Not much soot, not much "knocking" going on.
I describe engineering as the practical application of science, we use the stuff that works, to the best of our knowledge, to solve practical problems within economic constraints.
@@ContinuousDelivery you’re presenting this as it it goes from the pen of the engineer to a beautiful design in flight. You acknowledge the iteration in the video (which i enjoyed) - the iteration is the soot. This is where we spend our time. We apply solutions with the best of our practical, professional knowledge - the economic considerations just keep the engine room sweaty
@@ContinuousDelivery If this process was truly linear from the mind of an engineer to the final product- we wouldn’t use version control software, what would be the point? you wouldn’t need to git if you simply had a great blueprint to work from
@@dickheadrecs Engineering has nothing to do with "linearity". Designing a car or a space ship is not a linear process, but it doesn't stop it being "engineering".
@@dickheadrecs Fair enough, if I misread your meaning, then I apologise. If you mean this as an analogy, rather than a reason to dismiss the applicability of "engineering" to software, then fine.
software developers/programmers are neither engineers nor craftsmen, we're management consultants :-)
the manufacturing metaphor is abused and does not apply very well
I have approached software development more from an engineering point of view, more discipline with good, better and best approaches.
I think of software design as a parallel to architecture. It has merged with art a bit, and heavy on engineering. There are objectively "good" buildings and "bad" buildings, but over the centuries, we have come to understand that poorly designed buildings fall down and kill people, a lot of them.
Software today is divided into life critical applications and non-life critical applications. I have worked on both (medical applications). The problem is that there is not enough recognition that software projects fall down. Our complexity is simply out of control, and many projects end when the software has too many bugs and not enough understanding. Programmers move on; the code was not that well understood to begin with. Most software isn't designed to be read. Printed out, its only useful in the toilet, which dovetails nicely with today's idea that software should not be printed. In the old days (1960s era), it was common to keep programs in printed form, usually annotated by the keeper. If I dare to suggest that a given bit of code is ugly, I am told that nobody is ever going to look at it, and it is going to be discarded shortly in any case.
If we are engineers, we are a funny bit. Electronic engineers don't produce schematics that are messes of spaghetti without much (or any) annotation. Same with mechanical engineers, or (say) architects. I'd like to say that software is a new science, and we are going to evolve out of this phase, but I don't think I will see it in my lifetime.
software as a craft (SaaC)
Most shops only make balls of mud, which is neither engineering nor craftsmanship. It's more like the anarcho-syndicalist commune in The Quest for the Holy Grail.
I’m somewhat of an Engineer myself, every programmer ever
The confusion those represent make me always ask for "Jedi Developer" title and (duh) "Jediism" go into my census as my religion.
It is somewhat ironic to hear you mention airplanes as the apex of good engineering when all software development processes in airplane design, especially for dangerous software, are V-cycle based, which you seem to dislike.
And you mentione one-off designing working through a process of iteration... But take a look at the ECSS standards. These are the European standards for designing space systems, including "classic" engineering as well as software, and they are not really iterative, much the opposite, they're very V-cycle based.
That's not to say iteration doesn't have value. It does. Any design process without iteration is dead in the water
Imo you get to a good conclusion when talking about what makes engineered seat-belts good: Realiable modelling and thorough testing. I think when we improve these two tools for software, a lot of its woes will go away.
It's not how SpaceX work though, or Bury Rutan, who pioneered fast cycle development of innovative aeroplanes. Also not how aeroplanes were developed during war time, when planes advanced more quickly than before or since. Cleary some of these aren't ideal for commercial flight, but still, it is how engineering works when building innovative things, and it is, increasingly, how engineering works, when building safety critical things.
Could you attribute the thinking of "engineering" to why some people end up in feature farm development models? When you remove the "craftsmanship" aspect of it...you end up with "does it work?" instead of "does it work and allow for easy change?"
There is nothing in “engineering” that works against “things being easy to change”. Commercial decisions may do that, like Apple making it hard to maintain iPhones, but that is commerce not engineering. In SW I’d say that working to maintain our ability to change things is what characterises good “engineering”.
calling it craft is like thinking alchemy is magic when it was mostly boiling piss
🥰