|
markrlondon wrote: and not have people directly say to him: "What the frug are you talking about?".
The sad thing is that he probably has them, but as many other "big fishes", he just ignore what they say.  
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.
|
|
|
|
|
Well, he does live in Washington state...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yes - it's the world of executives and wannabes who hear/read that and think, "wow, he's really good. I wish I could be so eloquent."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Guess I better double down on disk space for my C:\temp drive.
|
|
|
|
|
Kent Sharkey wrote: a platform dedicated to productivity
And I thought they made it for profit...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
As developers, we read a lot of code. A typical code reading task is to scan through a class definition in a header file, in order to understand what the class is about. "Express yourself. You've got to make him express himself"
|
|
|
|
|
Upon digging through the company’s terms of service, an eagle-eyed Twitter user discovered that beta testers were signing up for a lot more than they might have thought. "We earth men have a talent for ruining big, beautiful things"
And I'm sure it will stand up in a court (for about 1 picosecond)
|
|
|
|
|
Kent Sharkey wrote: "We earth men have a talent for ruining big, beautiful things"
Like our view of the night sky.
|
|
|
|
|
Kent Sharkey wrote: that beta testers were signing up for a lot more than they might have thought.
Is that not the usual practice with / the existance purpose of the Terms of Service and the User agreements?
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.
|
|
|
|
|
Elon, always planning ahead.
Elonville and Musktown, here we come.
|
|
|
|
|
Why does it take so long to build software? We hear variations of this question frequently Those scrum meetings and TPS reports take a while
|
|
|
|
|
Kent Sharkey wrote: Why does it take so long to build software?
Does it take long? MS has been releasing two new versions per year for a while... It should not be that difficult 
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.
|
|
|
|
|
... because you're not spending any time on analysis and design? (Pay me now or pay me later ... at double the rate)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
When I started my computer science degree in 1988 were were given 2 hours of machine time per week.
Hardly anyone on the course had a PC and we were not "allowed" to start coding anything until our design had been accepted by the course tutor.
After you had got your design on paper approved you needed to make good use of those two hours because they disappeared very quickly if you were not sure of what you were doing.
I have found myself working from "User stories" that state things like "all the relevant fields are displayed" - I actually think that things like NPM have encouraged more of a mess because we are encouraged to just jump straight in and be "agile" rather than consider what we are going to do.
The tortoise and the hare story exists for a reason.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 3-Nov-20 3:19am.
|
|
|
|
|
I come form "flow charts" and desk checking. I learned about machine hours too; except all my time was spent running test cases for QA trying to keep up with the speed of development (I wasn't "compiling", as I explained).
I used to go to the art store to buy things like "French curves" in order to make DFD diagrams for my clients. I then moved on to Visio. At some level, I can't function without some diagramming. I don't know how others manage without. They've established a level of mediocrity which has become the standard (i.e. Agile).
I did "agile": 13 planned releases over 26 weeks. Some 10 developers. Hit every milestone. Preceded it with 6 months of analysis and design though; and another 6 months for the "DBA's" to "get it" and to see that "our" DB design was also spot on.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: I did "agile": 13 planned releases over 26 weeks. Some 10 developers. Hit every milestone. Preceded it with 6 months of analysis and design though; and another 6 months for the "DBA's" to "get it" and to see that "our" DB design was also spot on.
That sounds fantastic
We get a two week sprint in which to understand, design and code the solution to a user story.
We do get refinement sessions in advance for each user story, although we are not "allowed" to specify any solutions within user stories which in my opinion defeats the purpose of refining a user story.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Sometimes these things require an overall architecture as in the case of a "pipeline" (revenue, goods, whatever).
Agile doesn't seem to acknowledge this. Everything is assumed to be automatically plug compatible; and no one seems particularly interested in the big picture. I don't last in situations where I can't maintain some sort of "lead" (i.e. I don't take kindly to orders, anymore).
The "fog of war" should be avoided at all cost, IMO.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: ... because you're not spending any time on analysis and design?
Don't you dare coming here with archaic riverfall ideas!
We are living in an age of agility and scrum. Analysis and design has no place in a modern world.
|
|
|
|
|
The documentation. Good grief, the documentation.
Estimated time to write software: X
Actual time to write software: 2X
Time to write docs: 3X
Testing: Well, something's got to give, right?
What do you mean you don't bother with docs? Next you'll be telling me you just redirect help queries to the web!
|
|
|
|
|
I've also seen something like
- time to write software that you will use briefly: x
- time to write software that you will use for a long time: 3x
- time to write software that other people will use: 9x
|
|
|
|
|
Another, similar one:
Resources to write a program: x
Resources to write a program componment (i.e. a program that must relate to and interact with other components in a comlex environment, adhere to standards, ...): 3x
Resources to create a program product (i.e. a program with documentation, a support line, marketing & sale elements, ...): 3x
Resources to develop a program component product: 10x
I think these estimates are roughly 40 years old. I have never seen them contradicted in practice.
|
|
|
|
|
I start out with the objective that the software shouldn't need documentation (other than tool tips) if it's done right. Match the user's "mental model". So far I'm succeeding.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: the software shouldn't need documentation (other than tool tips) if it's done right. Match the user's "mental model"
In principle I agree but the difficult is getting to the user's mental model. Often, people simply cannot describe it accurately themselves. It needs to be teased out with long user interviews and testing, ideally. This can be difficult to arrange.
|
|
|
|
|
Because while you can get a degree in Computer Science, all the way up to Piled Higher and Deeper, very few people actually are skilled at the art of software development.
|
|
|
|
|
Because programmers rely on the latest and greatest tools as marketed by salesmen who, in their previous incarnation on earth, were selling snake oil.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
