|
charlieg wrote: Margaret is legend.
I agree. She is an amazing person. 
Every time I read an article or excerpt about her work I am always inspired.
And you won't regret getting this book so far (chapter 2) it is fantastic read.
So much great stuff in there.
|
|
|
|
|
Nice. We built a new internal service this year, for inbound files of the same magnitude.
Because it's very important data, I designed the system to automatically recover from a broad set of unknown failures, with redundancy in place that gives us a 2 month leeway to get the automated system back on track.
Extra attention was made so we could re-create scenario's on a disconnected environment easily, and audit both production and simulation process with very basic tools.
So far we've had 7 failures, with a critical versioning failure last week.
No impact at all because of our redundancy.
When dealing with large volumes or critical data, you really need a sensible and simple failsafe.
|
|
|
|
|
I found that (user) logging reduces a lot of "errors".
Another term is graceful degradation. But that requires understanding when a try-catch block should continue or not. And, yes, it may require asking the user if it should proceed (e.g. a file not available).
It then comes down to transparency (of the software) ... what Boeing failed to do with their software changes: tell the user what they did and how it might impact them.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
The Boeing thing shows that big Engineering can be really hard, and that in many cases, software is just another unreliable component, somewhat miss-designed and under appreciated (in its failure modes!).
The world is eating software, with the usual outcomes.
|
|
|
|
|
Very good points and exactly right on the Boeing problem. Could’ve been solved properly. Such a sad and terrible thing.
|
|
|
|
|
It's just shocking to me how many "professional" developers don't embrace defensive programming.
|
|
|
|
|
I believe it is because they don’t “have to” since they are not the ones who will be wakened in the middle of the night. You learn a lot from losing sleep. 
|
|
|
|
|
One of the hardest, or at least most memorable, software problem I ever had to chase was a programming error in a seldomly used error recovery routine. It seems my programmer, who was highly experienced in other programming languages such as COBOL, coded a "=" instead of an "==" inside an if statement in a C program--kinda like "if ( A = B)....". This ALWAYS returns true WHILE assigning the value of B to A.
Unfortunately, this little error caused the system to crash.
It took about six months to find the cause of the crash and understand what was happening. Looking at the code under the pressure of a "down system", we always asked why the condition was true because our mind was saying if A equals B and not considering that A was not equal to B before the if statement.
I cursed (and still do curse to this day) whoever decided that allowing an assignment inside of a conditional statement was a good idea.
And I have to wonder how many systems, like autonomous cars, have a statement like that buried way down deep in a infrequently used piece of critical code.
|
|
|
|
|
That is a fantastic story, thanks for sharing.
I’ve seen that error (in my own code) and fortunately caught it before it went into production. You would def think the compiler would catch that.
|
|
|
|
|
More from this fantastic book, Modern Software Engineering[^]
Quote: In his excellent talk called “Real Software Engineering,”3 Glenn Vanderburg says that in other disciplines “Engineering means stuff that works” and that almost the opposite has become true for software.
Vanderburg goes on to explore why this is the case. He describes an academic approach to software engineering that was so onerous that almost no one who had practiced it would recommend it for future projects.
It was heavyweight and added no significant value to the process of software development at all. In a telling phrase, Vanderburg says:
[Academic software engineering] only worked because sharp people, who cared, were willing to circumvent the process.
That is not engineering by any sensible definition.
Vanderburg’s description of “engineering as the stuff that works” is important. If the practices that we choose to identify as “engineering” don’t allow us to make better software faster, then they don’t qualify as engineering!
Software development, unlike all physical production processes, is wholly an exercise in discovery, learning, and design. Our problem is one of exploration, and so we, even more than the spaceship designers, should be applying the techniques of exploration rather than the techniques of production engineering.
Many of us have been bashed over the head with “software engineering” only to discover over time it was nothing related to any kind of engineering.
|
|
|
|
|
Indeed. Very little software is engineered these days.
|
|
|
|
|
I agree. If we built dams or sewer systems like we do software, we're all getting wet.
Engineering is a hard science. Software "Engineering" has yet to be defined.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I agree that using "engineering" in the context of software development is misleading. Engineering is far more formalized than software design, partly because it has a longer history, partly because things like physics and chemistry apply, partly because there are fewer bespoke solutions, and partly because an engineered product isn't expected to be enhanced with an endless stream of new "releases". The sentence about "Software development...is wholly an exercise in discovery, learning, and design" is bang on and has been stated as "Let the code speak to you".
|
|
|
|
|
Greg Utas wrote: an engineered product isn't expected to be enhanced with an endless stream of new "releases".
Apple Corporation might disagree...
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
What product are you talking about?
|
|
|
|
|
My first 3 reactions, granted coming from about a quart low on coffee were:
- What level of dumb is this?
- Does Git use Okta for logins? 
- One would think that with what Okta charges, they might have their source in a veritable fortress
Granted, this comes from a place where we don't use Git at all, except to reluctantly download packages when there is no other choice...
|
|
|
|
|
|
|
We currently use AWS Cognito, but were starting to look at Okta. yikes, maybe not...
|
|
|
|
|
On the bright side, Okta's source code will be given a serious review for vulnerabilities.
|
|
|
|
|
|
It might hurt Oktas bizniz model. I would not regard it as a threat to security. Any good security model depends on math, not on secret algorithms.
E.g. [sufficiently] hashed passwords, or ECC [^]
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
What the heck is Okta? Seems like it has to do with authentication? Why do we trust these services???
|
|
|
|
|
I just visited their web site. It appears that they bill themselves as a "one stop shop" for all your authentication needs.
Given that they've just been hacked, I don't know what would worry more as a client - that they are using their own solution internally, or that they are not.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It wasn't Okta that was hacked. It was GitHub.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
