|
I understand my windows update experience, and that's why I use Linux now.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
It’s been said that 90% of programming is debugging (and that the other 10% must involve writing those bugs). Don't forget to update the docs
|
|
|
|
|
Quote: What happens when you find a decades-old bug?
Never touch a running system?  
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.
|
|
|
|
|
Most bugs are not documented, so there is nothing to update.
(Incidentally, the same applies as well to code that are bug-free, or assumed to be bug-free.)
|
|
|
|
|
With all due respect: read the article
TTFN - Kent
|
|
|
|
|
You are right - I did write my comment before reading the article.
But what the article says is just the same as my comment said: Documentation is ignored. In this case, although there were some ancient, tiny starts on some documentation. Further development just skipped the documentation part. As if it wasn't there.
I uphold that ignorance of all sorts of documentation is a major problem in software development. Documentation is "out of sight, out of mind" for the great majority of programmers I have been working with. Furthermore: When I do document my own code, my co-workers simply ignore it: Rather than looking in our documentation base, they come to me to ask how things work. I give them the link to the exact doc page they need, and the next day they may be back to get another doc link, which was included in the first page as a "For more information on ..." link. (I am not making this up!)
Sometimes developers even fight documentation actively: A number of years ago, I was engaged for a couple years to develop the (online) documentation for a web service - the developers more or less refused to "waste" time on non-coding tasks (not considering javascript to be "coding") like documentation, so I was hired to do it. I remember in particular one episode where this one developer fiercely sneered at me (and at that, she certainly was a master!) when I was asking for some information about her modules: I've got a lot more important things to do than to feed you with stuff!
I can't remember last time a programmer gave any sort of praise to documentation. Not in modern times. 30+ years ago it was different: When I left my first job after getting my degree, my notice period was set to be the time it would take me to complete the documentation of the subsystem and the code that I has been responsible for. In those days, documentation was essential. But we weren't agile in those days.
|
|
|
|
|
trønderen wrote: I uphold that ignorance of all sorts of documentation is a major problem in software development.
This (and your other points) are painfully true (and I suppose was also a factor in the lack of update of the docs in the cron case in the article). I don't know if it's due to the "faster, faster" mindset of development these days, the "the code is the documentation" mindset, or just plain laziness, but docs often are the last thought.
People used to beat on MSDN frequently (and almost as many kick at docs.microsoft.com), but the support on many of those pages were better than many SO discussions.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: What happens when you find a decades-old bug?
No one believes you.
It's like pointing out that something that is a 'common industry practice' is actually illegal, contrary to best practice, or outright insane. No one takes the observation seriously... until one day when all hell breaks loose and people start going to prison or having to set up massive industry funds to compensate customers for what was always an illegal 'common industry practice'.
Take away point: Just because no one has noticed it before or just because everyone is doing it, doesn't make it ok or harmless.
|
|
|
|
|
In a (very) long technical career, I must have been exposed to the majority of software methodologies, and experience has shown that they are, by and large, more of a liability than a help. But the medium is the message? (but I'll take an XL)
|
|
|
|
|
"The process is not the product."  Kudos to the author for being succinct and accurate.
|
|
|
|
|
Quote: Individuals and interactions and processes and tools
Working software and comprehensive documentation
Customer collaboration and contract negotiation
Responding to change and following a plan
In direct contrast to the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Why? Because the Agile Manifesto creates tension between frequently opposing forces, leading to imbalance and extremes, which is one of the reasons Agile Development fails in actual implementation. Conversely, I prefer to find the appropriate balance between the two, as appropriate for the client and the task at hand.
I blogged that 5 years ago.
Quote: The process is not the product
Exactly.
|
|
|
|
|
Popular programming language, at the top of its game, still struggles to please everyone Traditional gift for the 30th is perl
Or maybe whitespace in this case.
|
|
|
|
|
Kent Sharkey wrote: Or maybe whitespace in this case.
I think enclosing brackets are better {} 
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.
|
|
|
|
|
With no payload, analysts are struggling to learn what this mature malware does. Hack different
|
|
|
|
|
Kent Sharkey wrote: With no payload, analysts are struggling to learn what this mature malware does.
I could think on a couple possibilities:
Option 1: Initial testing for something bigger coming later
Option 2: Showing the middle finger to all those "Mac has no virus"
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.
|
|
|
|
|
Maybe it's like Desmond Bagley's Running Blind, in which the Soviets are allowed to get their hands on a complicated circuit that actually does nothing useful, in the hope that it will busy out many of their best analysts.
|
|
|
|
|
Quote: Once an hour, infected Macs check a control server
The question from a network noob: And it is not possible to locate the root?
modified 27-Mar-21 21:01pm.
|
|
|
|
|
Compiled, the Xceed DLL consumes 635k. I only wanted it for one control, so I took a few runs at cutting out just what I wanted, but on my 3rd attempt, I still had over 50 files and it still wasn't compiling. I gave up and rolled my own control.
The source code to my control is only 16k. I'm gonna count that as one for the "W" column.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: The source code to my control is only 16k
JsopXceed, not Xceed WPF.
Never felt a need for controls that do different from Windows' standards.
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.
|
|
|
|
|
Well, the xceed library is pretty nice, and includes a lot of stuff that should have been in WPF to begin with. Of course, that’s true of pretty much any framework delivered by Microsoft - a lot of common sense controls that should have been provided.
Also, my size estimate on the compiled xceed library was way off. Compiled form is actually 1.3mb.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: a lot of common sense controls that should have been provided.
Standards. Thought in school, that anyone knows how to use. Where third parties have a non-mentioned call of helpdesks. MS Controls are predictable, have been seen ComCtrls.
#realJSOP wrote: Also, my size estimate on the compiled xceed library was way off. Compiled form is actually 1.3mb.
Given today's computers. 1.3 Mb, my dear Goddess, save us.
So, I will have to try it; if you use it, then there a reason for that 
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.
|
|
|
|
|
I started programming when 64k was considered a LOT of memory and hard drives weren't yet available. Conservation of resources was a big deal back then, and I still code as if all of that still matters.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Quote: I gave up and rolled my own control.
Modern Software Engineering 101.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
