SoylentNews is people
SoylentNews
An outrageous, insightful, and sadly accurate commentary on programming. I found this an extremely entertaining read and agree with most of it. It doesn't offer solutions, but certainly highlights a lot of the problems.
"Double you tee eff?" you say, and start hunting for the problem. You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.
Personally, I think things will only get better (including salaries) when software development is treated like other engineering disciplines.
(Score: 3, Insightful) by egcagrac0 on Thursday May 01 2014, @02:21PM
If you want to be treated like engineers, then you'll need to act like engineers.
All changes will need to be initiated by a change request, thoroughly designed and documented, approved by signoff from 6 different departments, and under formal release revision control.
Expect no more lone cowboy lifestyle if you want ot be treated like an engineer.
This is what "software engineering" produces. [fastcompany.com] This team deserves to get treated like engineers... and they probably are.
(Score: 2, Funny) by Anonymous Coward on Thursday May 01 2014, @02:30PM
Never fear, GitHub will fix everything! It's like social and cloudy, bro! Commit to git and the cloud will fix your shit!
(Score: 4, Insightful) by Ethanol-fueled on Thursday May 01 2014, @02:47PM
If you work for a place that does things properly as you suggested, there will already be numerous strict specific guidelines and a version control system for software/firmware departments.
If you work in a place stuck in a garage mentality like I do, where the version control system is e-mail and stashing your fistful of source files in some shared desktop folder on the Starcraft server, chances are the engineering department's gonna be similarly run.
Sure, there's a document-control system and a numbering scheme, but people are going to be pencil-whipping those drawings when they should be checking them, and then once those changes are implemented an ECO or whatever is released but nobody is made aware of it, and then you have a NASA-style disaster where people are building stuff in SI units while the drawing now calls out inches and shit.
tl;dr - Both software/firmware and engineering departments can be run well or like shit.
(Score: 2, Interesting) by Anonymous Coward on Thursday May 01 2014, @03:04PM
Not to mention that if your code fails, you lose your license to make a living. If it causes damage, you go to jail.
It may seem harsh, but that is the way it is for real engineers. From the view of an Information Assurance manager, the most dangerous threat is not hackers, or terrorists, or APTs, or the NSA, or competitors, it is programmers. The vast majority of security flaws are found in code, not in implementation where they should be. Until programmers are held accountable for their own failures, intentional or not, they will be regarded as nothing more than very expensive keyboard pounders by PHBs, and rightfully so.
(Score: 3, Insightful) by tibman on Thursday May 01 2014, @05:19PM
That doesn't sound like software engineering, that sounds like a lot of red tape for no reason. Change requests don't need to be signed off, the new implemented code does! Nobody should be unable or afraid to make changes to the code. If they break something while refactoring a test will fail. If new code is written it is because a test made them do it. If they fix a bug or add a feature, who cares. If business decides they don't want the bugfix or feature then they can reject it. Needing permission to fix a bug is bad bad bad. Those systems are full of bugs because it takes more time and effort to get the change request approved than to just fix it while you're in there.
There is almost zero need for documentation inside of development. The code (and tests) is the documentation. If someone writes a companion document to describe what the system is doing then there is zero guarantee that it is what the system is actually doing. Business can make all the documentation they want but development has no need to ever see it. Saying you need documentation is like saying an architectural blueprint isn't good enough to describe the building and making a word document that describes how the building should look with some photoshopped images. The building architects don't need that word document, the laymen do. Code documentation in software engineering is for people who aren't the software engineers.
A software engineer makes no change to production code unless a test is failing. Period. A software engineer has no problem with someone peer reviewing (they desire it!). I apologize for the ranting, i'll stop. To each their own i guess : )
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Nerdfest on Thursday May 01 2014, @05:42PM
You're my new best friend.
(Score: 1) by mrMagoo on Thursday May 01 2014, @06:16PM
That's because they are describing a CMMI Level 5 shop.
A real one; not the fake Indian kind.
CMMI Level 5 is what you use when lives and billions of dollars are at stake.
A bridge would be a CMMI Level 5 job.
However, Level 5 is way inefficient. It's really kind of commercially unfeasible. Most production shops run at Level 3.
Software engineering needs more discipline and process. However, it doesn't need to have shackles attached to its ankles.
A lot of "traditional" engineers are pretty spiteful towards software, as they see us as a bunch of hippies.
I am in a position where I am trying to marry an ISO9001 process with badly-needed innovation and flexibility. The last few years, I let the process folks have their way.
The pooch was royally screwed.
I now need to force them to let go of their death grip, and work out a less restrictive methodology that will actually allow my organization to create competitive software.
Fun stuff.
I love the guy's rant.
"Good judgment comes from experience. Experience comes from bad judgment." -Originally attributed to Nasrudin
(Score: 2) by egcagrac0 on Thursday May 01 2014, @08:01PM
You're absolutely right, of course. Go ahead and play with it, except it doesn't go live until it's been thoroughly vetted and blessed.
... only "playing with it" is usually not something I see the engineers do. They get informed of a specific problem, and design a specific solution to address that problem while attempting to not introduce any new problems.
That's not a particularly engineerly attitude. The engineers I see make careful notes about what changes they're making and why, and usually have a brief discussion of their design decision (and why any obvious alternates were rejected) in their notes.
Interfacing with the laity is important; they're usually the ones who sign the checks.
(Score: 2) by tibman on Thursday May 01 2014, @11:52PM
The engineers I see make careful notes about what changes they're making and why
You're completely right. One of the very nice things about writing software is version control systems. Any change you make and "commit" has the specific things you changed, a comment why (optional), and usually a relationship to the task that told you to do it (mostly for time-tracking reasons). Then usually someone will come behind you and check what you changed and have a discussion with you about it.
Interfacing with the laity is important
You're right, i was far too flippant. I apologize.
"playing with it" is usually not something I see the engineers do
Now this is a difference between my experiences and yours. In my experience, software engineers enjoy the challenge of attempting to optimize or better organize something. Sort of like the boyscout rule of "leave it better than you found it". They salivate over the thought of completely rewriting a piece that everyone hates.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by egcagrac0 on Saturday May 03 2014, @04:57PM
I think one of the differences here is you're talking about software engineers, and I'm talking about hardware engineers (EE, ME, etc). If we're discussing the idea that the software guys should be treated with the same kind of respect as the "other engineers", I think it's valid to compare the different behaviour patterns.