Talking about software let's leave aside software that needs formal approaches, such as medical, avionics, etc. And that's the root of all evils. It is not even close to engineering. My observations are that university graduates majoring Computer Science or Software Engineering are just not ready to do production-quality work.
That's what "formal" training can achieve for the current moment. Then these guys start working - most likely their first job is going to be an apprenticeship, where the more senior developers are tuning their theoretical knowledge into the practical stuff of getting things finished in time and within budget.
Craftsmen are just filling in the gap of how a graduate can get to the next level through disciplined practice and apprenticeship. But there's one thing I can agree on. The sheer amount of average developers no matter what they call themselves engineers, agilistas or craftsmen are just plain mediocre at what they do. This leads me to the conclusion that maybe our profession is closer to writing - there aren't too many good writers, are there? In practice however, no code is clean enough that this would be an easy task, or you loose runtime stability just like you can wire any chip in a logical analyzer leg-by-leg fashion, yet you don't want to do it for a production system.
Again, construction of software costs paid worktime. If people don't realize this, it just costs more and more time. Most coders write 0 number of prototypes: they do the real system. It's like handing over the FPGA to the customer as the finished product. Please note: nowadays electronic engineering is also handing over the FPGA firmware.
A cost for a new FPGA isn't zero, but the cost of having no formal approach can be a disaster. What I claim here, is that the design activities aren't to be missed and that the craftmanship and most agile movement - despite every attempt of their inventors - are entirely dropping design and forward thinking on the base that construction is free anyway, if we did an error, we just go back and fix it.
Hi Vladimir, While it's really nice to see the code catas, what it reminds me about is simply a cargo cult. While the question-answer system of design is a pretty good approach see Alexander's Notes on the Synthesis of Form as an example , it is also widely known that a higher level of self-consciusness is possible see also there. As for your comments on engineer graduates, I'm sorry to tell you that architect graduates cannot be used as full-blown architects, and this is usually even restricted by regional laws.
It's easy to go from the Architect's wikipedia definition to this article: en. It feels to me that most practiticioners of development who are arguing here have never ever looked after what do architects or other engineers really do, how are they educated and what do they deem important, but instead try to get it from a layman's perspective.
That formal training has a lot of good parts:for example, it tells you if a system is complete in certain senses. But it also tells you how to apply systematic approaches to requirement elaborating, testing, and any other elements of a software construction flow. While I understand your frustration that these aren't "burned in" enough yet, the university has no intent to burn it in, exactly as to let people have some specialization by their first years of practice.
Its unfortunate, however, that those people "already out there" mostly don't know about these. My first question to junior developers about certain set of problems - like, typically, how to start elaborating requirements, or how to distill design from them - is the question: "What did you learnt in school for that? Without this however, the next generation will forget to use it too - to the level that now, much to my surprise, I'm standing nearly alone to defend certain values. One last thought: Those things they teach in school didn't came while doing nasty things under an academic desk: they are stories and conclusions of real-life developments from the 60s to the 90s.
Everything you see from UML diagram styles to development lifecycle styles were proven solutions for real-life problems before they got into the education realms. I'm not into the logic that they were academic assholes who don't know how to solve today's problems. I feel such thinking is short-sighted, and its prevalence saddens me a lot. Hi Adam, Don't get me wrong! I'm personally involved as a lecturer in the Sofia University. I do see value in education. I do see value in being theoretically prepared.
I do see value in being well informed and went through at least some of the chapters of Ivor's Jackobson Software Engineering in Practice or something similar. What you just told me is that academic curriculum is like that because it has to pass to the students only solid proven, research backed-up, real-life problems solving knowledge.
This simply doesn't work! And it doesn't matter whether the candidate is a fresh-out of the university, or with many years of experience, or with an impressive CV and experience that is far-more rich than mine for example.
Why so many software guys are at that dire straights level of skill? I'm sure that architecture or civic engineering graduates are in a pretty similar situation. It's logical to conclude that what they do is also a craft and not quite engineering. The only thing that makes it an engineering is the high level of standardization of the basic parts and the potential of vast multiplication of simple materials.
And the fact that they're just bit better at repeatably building successful arcs in a predictable fashion, right? But when it comes to building something really, really unique, do we have enough data about how successful are architects and engineers? Or we're just assuming they're really good at that? In software there aren't such really basic parts and materials - technologies and patterns are at a way more higher-level of organization than simple reusable parts.
Another point to ponder is that it seems to me that all current software design principles and maxims are possible to be followed only by professionals with higher level of self-consciousness. And how do you get to that level? Certainly not by academic training and certainly not by following software engineering books. And certainly not by imitating the way engineers from other fields are working. Craftsmen practices are yet to be research backed-up and solid proven.
But I see them working in the field and for me this empirical knowledge is a quite good approximation on which I can successfully rely. The engineering analogy can be as short sighted as everything else. So, why not trying out some other analogies? Yep that's the main advantage and yet the main problem of software development. If a car has a design flaw, you need to recall it to fix it which cost a lot of money.
As for a software you just send a patch which is almost free for the developers. But ask your customer how much a bug can cost him in lost time Maybe some developers work for free, but the companies I've heard of employ their employees with the full cost of between to EURs a month. Hi Vladimir, Theoretically prepared A craft is different from some kind of science even engineering science that it has some scientifical basis.
Software engineering has scientifical basis by nature: otherwise we wouldn't have operation systems or graphical representations. However, most of the developers are just users of advances in fields of Computing Science and Software Engineering. This is bad on one side. On the other side, a general practitioner doctor is also just a user of recent drugs, even if he is the one to answer on the field for unique needs; so is an architect selecting which kind of brick or window to use.
Also, you can employ a library for nearly anything. You never had to think about wether you can use the "class" construct in a programming language, most of them has it built-in with javascript as a well-known exception in some regards. Our basic parts are concepts: the concept of a class, the concept of a drop-down select, the concept of a QR-Code reader. They are ready-made and available for a vast array of platforms.
However, in recent years there are also serious problems for sure. Also, they do avoid collapses as it would cause physical damage to people and personal damage to themselves architects literally go into prison after such, regardless of how much the customer insisted of a given feature.
It is personalized to the customer's needs, of course, but so is an office building. By demanding academic knowledge and background check every single time a problem arises at the student's first workplace.
It worked so far, all of my "students" as I called them became development team leads sooner or later. It also needed their talents of course. Craftsmen practices are yet to be research backed-up and solid proven While I have nothing against some practices - like, formal specification based development, which they call TDD - the term craft can be nothing more than cargo cult. Once their practices get research back-up it should be a part of the standard software engineering curriculum, that's all.
So, it's not the practices, but the viewpoint which makes me worried. Because a programmer costs a huge amount of money, and as long as we think of software construction as free, our employers and customers will loose multiple houses worth of cash every single month based solely on that assumption.
If something is based on science, even if it's closed into code libraries, and yet it has signs of an art, and has to be adopted for each environment, I call it as engineering. Analogies are just as worth as the viewpoints we look it from. I look the analogy of a craftsmen as the quality of things I see at a usual fair. I look at the analogy of engineering in terms of background and science. I just freak out if I think of a future were formal education would be seen as non-essential, in case information technologies would be such important for our society as they are now.
I literally see the craftsmanship movement, that although their practices are well-intended, the pure analogy to compare software construction to craftmanship is defining darkness as standard, to quote the old Microsoft-joke.
Their practices are welcome as a part of software engineering practices, though. Adam, From this response it is clear to me that you haven't done any real Engineering. For Electronics you would have to reconfigure the whole assembly line. That means new templates for the PCB's and new tooling. I've watched the video now and Glenn is spot on. Which begs the question why are you so stuck on this single metaphor?
It seems to me that for you the title of Engineer bestows greater credibility and kudos then that of Craftsman. Well if your code is crap it doesn't matter what you want to call yourself in my book : Which brings me to my next point.
If you produce code where you can't swap out the persistence layer relatively easily then I would say that is pretty poor. A design goal should be a clear separation of concerns. Persistence is an orthogonal concern and should be addressed as such. Spaghetti code where everything is horribly coupled to everything else is expensive to re-configure I agree.
I wasn't assuming spaghetti code though. I was assuming clean code written by skilled professionals. I agree that over 40 years of Software Engineering has left us with unskilled practitioners that produce crap code that is expensive to maintain.
Adam, Just one thing that you're totally missing. Building software is about creation, writing and it is rarely a construction. It's about emergence, shared conceptualization which happens not inside of a factory, but in a social setting. It's about language. You're leaving me with the impression that to you the emergence of human language had happened as a result of some sort of scientific research. In Programming there's something more than engineering - there's some sort of spontaneity and a moment of illumination.
A design activity strongly bond to language. I would never refer to language as to basic parts. Zeros and ones - these are the basic parts we can reuse. He says the same things about architecture, and defines it as a language, and its conceptualization according to him should happen in a social setting. Basically everything you say about writing applies to architecture in his view.
If I'd claim anything about emergence is that builders of cathedrals had respect of their history, whereas in our current situation, the persistent notion is the "everything before was wrong" approach, which applies to Craftmanship as well as to Agile, and - funnily - applied to OOP vs Structured Programming before its proponents seemingly didn't deal with the fact that the class construct appeared one of the first times in the Dijsktra-Dahl-Hoare book on Structured Programming.
I'd claim that roman architecture and gothic architecture are both architecture; I'd claim that there's much more to build something large then being a craftsman; I'd claim that if it was languages, the relation of software development to its state 20 years before should be the relationship of modern greek versus antic greek, rather than italian versus latin.
If I had to define a basic part, I'd rather concentrate on a CPU instruction set, or similar, as zeros and ones rarely occur to be actually defining anything, 0 and 1 weren't the ones where we began. Paul, Let me state something: in outsourcing, where I spent the largest part of my professional carreer, you get what you get. It's not me who produces crap code, it's already there I'm afraid. My job for that time was to stop people continuing the tradition of spaghetti code.
My internal memos of code conventions are still required course material long since I've left. I was well-known for "maximalism" when it came to so-called internal quality. Then I switched to in-house enterprise development, and seen where did those spaghetti codes came from.
It came from the very people who defied SE practices. It came from "The Scrum Company", which I don't want to name here, it came from people who defined themselves "agilists". I met also with one of the largest agile coaching companies. I was horrified by their ideas on how software should be developed.
In general, the strongest tests of hypotheses come from carefully controlled and replicated experiments that gather empirical data. Depending on how well the tests match the predictions, the original hypothesis may require refinement, alteration, expansion or even rejection. If a particular hypothesis becomes very well supported a general theory may be developed. Although procedures vary from one field of inquiry to another, identifiable features are frequently shared in common between them.
The overall process of the scientific method involves making conjectures hypotheses , deriving predictions from them as logical consequences, and then carrying out experiments based on those predictions. A hypothesis is a conjecture, based on knowledge obtained while formulating the question. The hypothesis might be very specific or it might be broad. Scientists then test hypotheses by conducting experiments.
Under modern interpretations, a scientific hypothesis must be falsifiable, implying that it is possible to identify a possible outcome of an experiment that conflicts with predictions deduced from the hypothesis; otherwise, the hypothesis cannot be meaningfully tested.
We can summarize this as an iterative process of:. We can map the scientific method steps into the process of the software development that includes knowledge acquisition and prototyping:. Where we Fail. Software development actually fails at most or all of these steps. The scientific method is typically applied to the observation of nature. As with nature, our observations sometimes come to the wrong conclusions. Just as we observe the sun going around the earth and erroneously come up with a geocentric theory of the earth, sun, moon, and planets, our understanding of processes is fraught with errors and omissions.
As with observing nature, we eventually hit the hard reality that what we understood about the process is incomplete or incorrect. One pitfall is that, unlike nature, we also have the drawback that as we're prototyping and trying to prove that our new software processes are better, the old processes are also evolving, so by the time we publish the application, it is, like a new car being driven off the lot, already obsolete.
We are, after all, attempting to replace a process , not just understand an existing, immutable process and build on that knowledge. How do we compare the training required to efficiently utilize a new process when everyone has "cultural knowledge" of the old process? How do we overcome the resistance to new technology?
Nature doesn't care if we improve on a biological process by creating vaccines and gene therapies to cure cancer, but secretaries and entrenched engineers alike do very much care about new processes that require new and different skills and potentially threaten to eliminate their jobs. And frequently enough, the idea of how an existing process can be improved comes from incomplete or completely omitted observation and questions, but begins at step 3, imagining some software solution that "fixes" whatever concept the manager or CEO thinks can be improved upon, and yes, in many cases, the engineer thinks can be improved upon--we see this in the glut of new frameworks, new languages and forked GitHub repos that all claim to improve upon someone else's solution to a supposedly broken process.
The result is a house of cards of poorly documented and buggy implementations. The result is why Stack Overflow exists. As to the last step, abstracting the prototypes into general solutions, this is the biggest failure of all of software development -- re-use. Although computing power and network bandwidth have increased dramatically in recent years, the design and implementation of networked applications remains expensive and error-prone.
Much of the cost and effort stems from the continual re-discovery and re-invention of core patterns and framework components throughout the software industry. Note that he wrote 17 years ago at the time of this article and it still remains true today. Reuse has been a popular topic of debate and discussion for over 30 years in the software community. Many developers have successfully applied reuse opportunistically, e.
Opportunistic reuse works fine in a limited way for individual programmers or small groups. However, it doesn't scale up across business units or enterprises to provide systematic software reuse. Systematic software reuse is a promising means to reduce development cycle time and cost, improve software quality, and leverage existing effort by constructing and applying multi-use assets like architectures, patterns, components, and frameworks.
Like many other promising techniques in the history of software, however, systematic reuse of software has not universally delivered significant improvements in quality and productivity.
The Silver Lining, Sort Of. Now granted, we can install a variety of flavors of Linux on everything from desktop computers to single board computers like the Raspberry Pi or Beaglebone. Cross-compilers let us compile and re-use code on multiple processors and hardware architectures. And script languages like Python, Ruby, and Javascript hide the low level compiled implementations in the subconscious mind of the program, enabling code portability for our custom applications.
However, we are still stuck in the realm of, as Mr. Schmidt puts it: "Component- and framework-based middleware technologies. What is engineering? Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations.
And we have the hubris to call what we do software engineering? And the "New stuff" certainly assumes that 1 it works, 2 it works well enough to be used, and 3 people will want it and know how to use it. Engineering implies knowledge, skill, and successful adoption of the end product. The Department of Energy Systems Engineering Methodology SEM provides guidance for information systems engineering, project management, and quality assurance practices and procedures. The primary purpose of the methodology is to promote the development of reliable, cost-effective, computer-based solutions while making efficient use of resources.
Use of the methodology will also aid in the status tracking, management control, and documentation efforts of a project. Engineering Process Overview. Notice some of the language:. This actually sounds like an attempt to apply the scientific method successfully to software development.
There are many engineering models to choose from, but here is one more, the Spiral Development Model. It consists of Phases, Reviews, and Iterations source :.
In each phase, the Custom Engineering Group CEG works closely with the customer to establish clear milestones to measure progress and success. This harkens a wee bit to Agile's "customer collaboration", but notice again the concepts of:. And the formality implied in:. True software engineering practically demands skilled professionals, whether they are developers, managers, technical writers, contract negotiators, etc. Certainly there is room for the people of all skill levels, but the structure of a real engineering team is such that "juniors" are mentored, monitored, and given appropriate tasks for their skill level and in fact, even "senior" people review each other's work.
Instead, we have Agile Development and its Manifesto source , bold is mine :. How can we fail to conclude that Agile Development is anything but engineering?
The Agile Manifesto appears to specifically de-emphasizes a scientific method for software development, and it also de-emphasizes the skills actual engineering requires of both software developers and managers, instead emphasizing an ill-defined psychological approach to software development involving people, interactions, collaboration, and flexibility.
While these are necessary skills as well, they are not more important over the skills and formal processes that software development requires. In fact, Agile creates an artificial tension between the two sides of each of the bullet points above, often leading to an extreme adoption of the left side, for example, "the code is the documentation.
From real world experience, the Manifesto would be better written replacing the word "over" with "and":. However this approach is rarely embraced by over-eager coders that want to dive into a new-fangled technology and start coding, and it also isn't embraced by managers that view "over" as incorrectly reducing cost and time to market, vs. As with any approach, a balance must be struck that is appropriate for the business domain and product to be delivered, but rarely does that conversation happen.
Regardless, Agile Development is not engineering. What is the primary activity of an engineer? It is design. A civil engineer designs a bridge that an ironworker builds. She designs a circuit that is printed on a board and populated by either machine or technician.
She writes the code that makes it work. There is little manufacturing involved in taking the made software and putting it in the hands of the person who will use it. Sometimes there is a deployment to a server or perhaps a CD is burnt and packaged in a box.
But often even these tasks are performed or automated by the maker herself. Historical craftsmen have always been makers. The potter makes a vessel; the blacksmith, a horseshoe; the weaver, a garment. These makers have always had close connection to the raw material of their work: the wool, the iron, and the clay. What then is the raw material of software craftsmanship?
What is the material of which software is made? The material of software is language. Java, Ruby, C, Scala, Clojure, etc. What makes this media so interesting is that the materials themselves are composite materials made of more primitive materials. Beneath Ruby code lies an interpreter built in C which is compiled by a compiler. Each new language emerges out of other languages as craftsmen explore the materials and invent new ways of combining and deconstructing what they have at hand.
Iron is combined with other metals to make an new raw material whose strength enables the construction of enormous buildings.
0コメント