|
Unicode arts by Sergey Alexandrovich Kryukov @SAKryukov,
Unicode Art[^]
high resultion ascii
modified 26-Nov-21 16:34pm.
|
|
|
|
|
honey the codewitch wrote: I don't know why I like coding in constrained environments so much Was your first an Atari XT, or a Commodore 64?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
16-bit Apple ][gs actually, but since I didn't have access to any of the 16-bit ROM toolbox information at the time, I coded on it in 65c02 (8-bit Apple ][ series) compatibility mode.
Real programmers use butterflies
|
|
|
|
|
When did we get old?
--edit
Yeah, I did. You aren't.
Witch.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
modified 26-Nov-21 19:41pm.
|
|
|
|
|
honey the codewitch wrote: don't know why I like coding in constrained environments so much
For the challenge?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
For the bondage?
|
|
|
|
|
Maybe. I want to say for the sense of accomplishment, but that seems just a roundabout way of saying the same thing.
Real programmers use butterflies
|
|
|
|
|
|
Everytime I hear this song I have to think of Modern Family - Wikipedia[^]
I didn't like it (my brother loved it) and sadly this song brings always a bad aftertaste to me
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
0x01AA wrote: Ray Charles - Hit the Road Jack Yeah. That's what she said.
Love that song
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Copycat!
I just sent that song to a friend a few days ago!
|
|
|
|
|
I am thinking about reporting you as to early plagiarist
|
|
|
|
|
Reading this fantastic book,
Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems.
Instead, the author likens Software Development & Design to the realm of Artistic Endeavour.
He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has.
*Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote: Why Software Projects Fail
As I mentioned earlier in this chapter, software projects fail at an astonishing rate:
In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail.
By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures.
Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time.
According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence.
Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this?
Here's some additional notes from the book that explain the author's point even better.
Quote: A McKinsey study of 5,600 companies found the following:
On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.
Of course, some projects come in on time and on budget. But these are likely the “IT” projects cited in the McKinsey study, which include things like datacenter moves, lift-and-shift projects, disaster-recovery site deployments, and so forth. These are complex projects (sort of: mostly they’re just big). I have certainly been involved in several such projects. They’re different than trying to conceive of a new software system that would be the object of design.
The obvious difference is that the “IT” projects are about working with actual physical materials and things: servers to move and cables to plug in. It’s decidable and clear when you’re done and what precise percentage of cables you have left to plug in. That is, many CIO IT projects of the back-office variety are not much more creative than moving your house or loading and unloading packages at a warehouse: just make the right lists and tick through them at the right time.
It’s the CTO’s software projects that run the greatest risk and that fail most spectacularly. That’s because they require the most creative, conceptual work. They demand making a representation of the world. When you do this, you become involved in signs, in language, in the meaning of things, and how things relate. You’re stating a philosophical point of view based in your epistemology.
You’re inventing the context wherein you can posit signs that make sense together and form a representation of the real world.
That’s so much harder.
|
|
|
|
|
|
You ask for it, but what is your opinion?
I think: Yes, an architect is needed to tell the staff what has to be build
|
|
|
|
|
I used to be a software architect, and I always felt the title was something of a misnomer. I was basically an in-house consultant and overarching team lead, for lack of a better way to put it. I still don't know exactly what a software architect is supposed to be. I used to think I did, until I did it. Frankly, I thought there would be a lot more UML involved, but I'm glad there wasn't.
As far as my job responsibilities, this was at more than one company, so it wasn't just one company's quirks.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I thought there would be a lot more UML involved, but I'm glad there wasn't
Ah UML. Another one of those things that is _fantastic_ & _amazing_ when used properly and _disgusting_ and _painful_ when used improperly.
I have used a UML diagram to communicate one specific point very quickly to an audience & it was amazing.
It got people to take action & understand system boundaries and more. It was such an amazing experience.
However, I've also been slammed over the head with UML tomes that are just a large brick of documentation that are really just for show purposes and it was terrible.
|
|
|
|
|
Likening software design to artistic endeavor is even more misleading than likening it to architecture. Architecture also has an artistic aspect, but it is also constrained by real-world feasibility and what the customer wants.
The folks who first documented software patterns were very influenced by the writings of Christopher Alexander, an architect who authored The Timeless Way of Building and A Pattern Language. But software had already adopted the term architect at that point.
Fred Brooks (The Mythical Man-Month, 1975) used architect to mean the person who specified a software system's capabilities and behavior, not its design. But since then, it has come to mean more of the latter.
Using architect is in some ways misleading, but does it matter if software architect has a generally agreed upon meaning? I'd also say that engineer is also somewhat misleading, but does it matter if software engineer also has a generally agreed upon meaning?
As far as failed software projects go, don't get me started. In my opinion, the biggest contributing factor is that hardly anyone sees their company as being in a software business. They typically view the software team as merely a cost center, and software as a necessary evil that is simply a factor input to an end product. When the importance of software excellence is poorly understood and rewarded, the company fails to develop or retain software architects and ends up paying the price.
|
|
|
|
|
Very good & interesting points.
Greg Utas wrote: The folks who first documented software patterns were very influenced by the writings of Christopher Alexander
The author mentions this exact book in this first chapter and takes it all the way back to 1968 NATO meeting... (underlined portion denotes the quote by Peter Naur at the 1968 meeting).
This is basically the first recorded occurrence of thinking of softwar devs as Architects.
Quote: The term “architect” as used in software was not popularized until the early 1990s. Perhaps the first suggestion that there would be anything for software practitioners to learn from architects came in that NATO Software Engineering conference in Germany in 1968, from Peter Naur:
Software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem. As one single example of such a source of ideas, I would like to mention: Christopher Alexander: Notes on the Synthesis of Form (Harvard Univ. Press, 1964) (emphasis mine).
This, and other statements from the elder statesmen of our field at this conference in 1968, are the progenitors of how we thought we should think about software design. The problem with Naur’s statement is obvious: it’s simply false. It’s also unsupported. To state that we’re in a “similar position to architects” has no more bearing logically, or truthfully, to stating that we’re in a similar position to, say, philosophy professors, or writers, or aviators, or bureaucrats, or rugby players, or bunnies, or ponies. An argument by analogy is always false. Here, no argument is even given. Yet here this idea took hold, the participants returning to their native lands around the world, writing and teaching and mentoring for decades, shaping our entire field. This now haunts and silently shapes—perhaps even circumscribes and mentally constrains, however artificially—how we conduct our work, how we think about it, what we “know” we do.
Greg Utas wrote: When the importance of software excellence is poorly understood and rewarded, the company fails to develop or retain software architects and ends up paying the price.
Yes, I've seen this too. I work on legacy systems which were written by novices who didn't even know how to create a database with keys. They literally created string keys for every table -- ugh!
Companies who don't know to pay for properly experienced people to write software definitely do damage that they pay 10X as much for -- and more.
Here's the great quote:
Red Adair said If you think it's expensive to hire a professional to do the job, wait until you hire an amateur.
|
|
|
|
|
In the Naur quote, it's dubious to claim that we should look to architecture for answers on how to attack software design. On the other hand, using Alexander's format to document patterns is quite reasonable, though it can get verbose.
I'm curious why the author harps on the use of architect. He says it "haunts" how we conduct our work, so he must have some opinions on how our work would be better conducted.
|
|
|
|
|
Greg Utas wrote: I'm curious why the author harps on the use of architect. He says it "haunts" how we conduct our work, so he must have some opinions on how our work would be better conducted.
Yes, he does have an opinion about it and that is really what the book is all about.
I'm about to start chapter 2 to get a better idea of what his frame of thinking involves.
Also, I think he is saying that using the idea of Architect has limited things in many ways.
People often get stuck in frames of thinking when they universally apply a term.
He's saying that the term Architect has led people down paths of thinking that has gotten them stuck in dead ends.
Now, many people (such as yourself it sounds) have understood that this metaphor (architect) only carries so far and then as a Real Practitioner (person who has written software to solve problems) often understand the nuances of how Architect does apply & doesn't and have overcome all terms because as Practitioners who actually have to produce a result we don't just get stuck on terms : we get the job done.
Some of the process of Real Software Development may be ineffable -- such as the way that Art sometimes is. You can't explain it, but you know it when you see it.
I'm reading the book not necessarily because I agree with him 100% but because I like to see all the nuanced explanations from all sides. I try to take what I like and throw the rest out.
|
|
|
|
|
Thanks for posting all of this. I'd be interested in your take on the book as you read through it. If it's full of shite, I'm happy to let someone else spend their time on it.
|
|
|
|
|
I'll read chapter 2 and try to post something explanatory yet succinct enough.
Its a long chapter.
|
|
|
|
|
Chapter 2 was extremely long and the author really went into the weeds.
Main Point Is What We All Already Know
There were some interesting things but for the most part what you discover -- as we who have been building software for companies for years have already discovered -- is that there is no One Process to developing Software. There are instead numerous ways to get to the same finish line. Whichever one works best for you & your team is the best.
Here are a few snippets from the book that show how far the author gets out into the weeds.
Quote: The Myth of Requirements
In system design, we speak of the “requirements.” This word creates a false center, a supposed constant, which creates problems for our field. These problems come in the form of a binary opposition set up between the product management team and the development team. It supposes, in the extreme form, that the product management team knows what to build and that the development team are passive receptacles into whom we insert this list of what they are required to build. Within an Agile method, some freedom is perhaps allowed to the development team in how to design within that list of requirements.
The requirements, however, do not exist. But the requirements, like everything else of value, are just made up by someone. They are not first known and then told. They are invented.
He compares this idea of inventing requirements to the act of creating a character in a story.
Quote: How do we know that Indiana Jones is the archaeology professor who finds the Lost Ark of the Covenant? Because George Lucas invented a character named Indiana Smith, and Steven Spielberg didn’t like the name so he changed it to “Indiana Jones.” And all of a sudden there is a world of the 1930s and a man standing in it and he needs to go do something and someone needs to get in his way and how might that work? That’s how requirements are made, in the movies and in software. People make stuff up.
When you make stuff up as a software designer, that world, like the world of the movie into which you posit a character with a conflict, is your context. It’s the place where you posit signs that have meaning in relation to one another. It’s your semantic field.
Quote: Semantics, as a field, is concerned with the production of meaning, and how logic and language are used.
Semantics = logic + language
This is almost the "Jerry Maguire Situation" from the author. In a night of passionate turmoil he makes meaning of everything and comes to the conclusion "We should all be nice to each other."
Oh, yes, shouldn't we.
In the case of this author, he is like, "Everything is language. Projects fail because we all have our own brains and all of us understand what we are building in different ways."
Oh, yes, that's right isn't it. but you can't quite fix that. Sheesh.
Here's a final quote from chapter 2.
Quote: The problem with software—a chief reason our projects fail—is a failure of our language. We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.
Our only material is that of language and ideas, names and meanings, signifiers and signifieds. Our only material is semantics.
So, the author is off the rails really. He found something that worked for him and which he can use to drive teams and their belief system to get things done well. But can it translate to other teams?
Probably. But probably because any passionate person with enough company-power and political-power can make almost any plan work.
Again, the point of it all is:
Find a process that works for you and your team. That will change as time changes and people change and the company changes.
|
|
|
|
|