|
Richard Andrew x64 wrote: Sunshine State (Florida)
Perhaps the good people of Florida should change the branding of their state. One never hears about the sunshine in Florida, only about the bad weather. 
I hope everyone comes through this storm safely.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Just saw this video this morning (safe for work), and it's worth noting that in Windows 11 24H2 Explorer apparently links to Recall.
Of course, their PR blah, blah says you can disable it (for now), but it's the whole frog slowly boiling thing going on. If it records your entire screen, you'd think there would be no reason for Explorer to link to it directly... unless it's also doing other things we don't know about.
Will I install 24H2 personally? Probably. Will I make sure I keep up with Linux if this gets worse? Damn right I will.
Food for thought.
Jeremy Falcon
modified 2 days ago.
|
|
|
|
|
The last commentary I saw was that Recall was not going to be enabled by default. Having said that, it's possible when the update is installed they give a decepto-prompt where it requires control-alt-left-fist-to-the-genitals to decline.
Software Zen: delete this;
|
|
|
|
|
...not to mention that, since just about everything in Windows is scriptable nowadays, I'm betting any script running as admin would be allowed to flip the setting.
|
|
|
|
|
data mining everything on your computer. This appalls me.
But it's not just Microsoft. I've used Quicken for decades, and a few years ago, they went to the dark side. They consistently re-enable backups of your files to the "cloud" where they assure all users the data is safe and private. Girlfriend looking at me: "please explain your hand in my pants...."
Charlie Gilley
“Microsoft is the virus..."
"the problem with socialism is that eventually you run out of other people's money"
|
|
|
|
|
charlieg wrote: I've used Quicken for decades
Gotta agree with you there, buddy. Their customer support is corrupt too, as far as I'm concerned.
Jeremy Falcon
|
|
|
|
|
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that:
- an Analyst Programmer needs to have a good understanding of both the business and the technology/systems
- by "best", I mean most efficient.
This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers.
Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception.
But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But...
His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs.
Remember... this just MHO.
modified 3 days ago.
|
|
|
|
|
I know a guy who's completely into the technology, but has no eye for businesses.
He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation."
Well, maybe not that bad, but you get the idea.
Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product."
That was way to simplistic according to him.
I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time.
Because I've worked with many developers who are like that I'm for the duo.
An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together.
They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either.
It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone.
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
|
|
|
|
|
The spec I just received sounds like it came from your guy. In a nutshell, it was:
- Remove hard coded Customer Type from routines A and B.
- Hard code Customer Type in routine C.
There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction". 
Sander Rossel wrote: Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
and sometimes they're right! 
|
|
|
|
|
Years ago I worked on a sub-part of a business application, that was written in Assembler. When the spec came over from the Analyst(s), it even told us which registers to use at each step.
|
|
|
|
|
I worked with someone like that Richard, his specs were so good/detailed/accurate he might aas well of coded it (and he could of).
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Yeah, been there done that 
Sometimes I just ask "what are you trying to achieve?"
And if they'll say "that customer type is not hard coded."
I'll follow up with "and how does that affect the outcome?" or something like that.
|
|
|
|
|
I've worked with people like that; they get completely engrossed in the detail to the point that they can't see (or explain) the bigger picture.
|
|
|
|
|
Oh yeah, but this works two ways!
As a developer I've sometimes been kept from the bigger picture.
For some reason, people sometimes see us as idiots who wouldn't get it anyway.
Probably because we're to up in our technology.
Now that I'm a manager myself I always try to get a tour of the factory (if applicable) for me and the programmer(s).
If it's not a factory I at least try to explain the overall process, like "we get document A in an email and after that they open our software and do X and Y so at the end a price is emailed back to the customer".
|
|
|
|
|
A small part of my job is to provide support for customers. I avoid get into implementation details, but I don't shy away from trying to explain, at a high level, why things work do they (or don't) either. I never try to sound condescending however.
I think most customers appreciate the fact that I don't treat them like idiots. At the same time, I don't "go deep" as I would with my developer coworkers.
It's a fine line.
|
|
|
|
|
Same!
I even have a customer who asks me about it and says he appreciates that I take the time to explain it to him in simple terms 
|
|
|
|
|
There are a lot of confusion between job titles and what they should actually do.
The Analyst Programmer will/should be responsible of the technical aspect on how to implement what the business analyst wants (after talking to the clients... )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I've been a solo developer in a small company for almost 25 years and I've hardly ever worked from 'specs'. An exception was the last web application that just rolled out a few months ago where the customer provided spreadsheets (order sheets) and said 'Make it look like this.' They also provided sample invoices and reports.
The project took around 9 months to 'complete' and so far (knock on wood) has been the best product rollout that I've ever been a part of. I attribute that mostly to the customer knowing exactly what they wanted and working from sample output/reports. We also had weekly teams meetings during development which I hated, but were essential.
Typically, our customers/end users have very little input into our product's designs. For the most part, our products are very niche and everyone on the team has > 20 years experience working either directly or indirectly in that niche. Customers rely entirely on us to make something that works. If they come up with a good idea, we steal it then charge them for it!
For the most part, there are no specs...we just make it up as we go.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
5teveH wrote: His mind-set is 100% that of a developer He has that "blind spot".
What you are describing is a business problem. Titles have nothing to do with it.
The basic hierarchy is
- Customer
- Requirement/business cases
- Architecture
- Design
- Implementation
- Test
- Delivery
- Repeat steps as necessary.
And there are other factors that influence that.
- Providing a solution that is robust, fast, etc.
- Updating old code
- Security
- Making sure that something is delivered so money can be made to pay the bills.
- etc
The roles that any one person might successfully fulfill depend on their own experience and their coworkers skill as well. An 'architect' might be able to fulfill the first 4 roles but not be great at the detail work needed for the levels under that. A developer might seem to have adequate knowledge of both the business and the code but fail when the business changes.
Of course failures can come from many places. I know of specific case where a service was created, delivered and successfully used but a contract very early in the company history guaranteed they could not make enough money to keep going. In another case a design or perhaps implementation decision lead to a multi-billion dollar company failing in less than a year due to a security problem. Or a developer that was handed a detailed design and decided to ignore it producing a solution that did not meet the business needs the design dealt with.
This is all impacted by complexity. A single man shop would need to provide all of that. But when a company has thousands of employees single employees just cannot learn everything needed to manage all roles. I have worked at companies where test automation was handled by a team of employees.
|
|
|
|
|
xkcd: University Commas[^]
Two questions:- Any UNICODE experts here?
- If there are, are there different code points for each type of comma?
This is what occurs to you when you wake up with the start of a migraine and you are working "chemically enhanced".
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: are there different code points for each type of comma?
Gnome characters says no. 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Comma, comma, comma, comma, comma chameleon
You come and go, you come and go
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
|
Wow, bit of a stretch. Nice try though
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
