|
Every new version of Windows is worse than the previous one. The horrors that await us in Windows 11 are so bad that they defy imagination.
|
|
|
|
|
|
It's not so much of a fear as a concern, in that it slows us all down considerably. No amount of software engineering or coding standards can fully eliminate this problem.
|
|
|
|
|
Remotely programming my toaster and coffee machine so that my toast
is ready at the same time as my coffee because the two devices don't
like each other.
73
|
|
|
|
|
There always, always... someone who is compelled to say something negative about other peoples work.
Not so much a fear, more of a PITA annoyance like nuisance phone calls. Time wasters.
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: There always, always... someone who is compelled to say something negative about other peoples work.
Oh god, yes - I've had review comments about my use of apostrophes in comments...
And that was working on safety critical code, where there are many, many more things to be worried about...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Because the are people that are so careless about what they write that everything they do is mediocrity...
Philippe Mori
|
|
|
|
|
... a host of .NET-based apps and web sites--12 years in the making--using some freeware language and CMS, like PHP/Joomla, or Ruby on Rails/Refinary, or Python/Django.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
An amateur has cobbled together an "application" in MS Access that fits his needs and now wants it to be a standalone product that he can resell.
Oh, and since it is 90% "Done" it should be just a few hundred dollars to finish it.
|
|
|
|
|
And as the saying goes... the first 90% takes 90% of the development time, the last 10% takes the other 90% of the development time.
|
|
|
|
|
Try an entire company "running" on Access apps. (See my nightmare, somewhere below.)
You have my uttermost sympathy, believe me.
Access should be banned as a weapon of mass sanity destruction.
|
|
|
|
|
happens to me on almost every job. we are doing an install and training at a customer's facility and I get notified by the customer or my boss that they got promised/promised that certain features would be included, but somehow never got told to me or written down anywhere. Now I've got to burn the midnight oil to get the feature built in.
|
|
|
|
|
In my current contract I have been trying to get the clients to send me their issues and DCRs. They seem to prefer to give these to me "word of mouth" rather than writing them down in an email or doc or even in the online system I set up.
The President of the company has a stack of these issues written up on his desk, but won't share them with me except individually. And when he does, it is one at a time, verbally of course, and he then takes that one slip of paper away again, back in the stack...
|
|
|
|
|
I hate spiders. So creepy.
But seriously, real answer is managers reading a new management book!
Happens every couple of years.
I would love to just program all day, and have an assistant do all my manager 'paperwork'.
|
|
|
|
|
Moving to an open office plan!!
Yes, lets lower morale and lower productivity for some short term cost savings!!
|
|
|
|
|
non programmer upper bee with no idea what it might take to hit said date. And then they start telling everyone that the newest and latest edition of said software or the new kitchen sink software will be ready on said date.
The worst is if you happen for some reason to hit a date in the past. They don't understand why you cannot do it in the future.
To err is human to really mess up you need a computer
|
|
|
|
|
You can choose Either the features or the due date, but not both!
I usually have to explain this to these people with the Empire state building.
Could they have doubled the size of the building and finished it in half the time?
What if they wanted it built in 1 day?
Okay... we realize because that is physical, it is not possible. Well, I promise you, software suffers from the same basic rules. The only difference is that people are willing to ship such horrible quality that as a building it would be condemned before opening, and nobody who looked at the building would go in. In the case of software this is merely HIDDEN (not visible)... The same issues can exist, and people have lost hard-drives, data, etc. etc. etc. from rushed software.
|
|
|
|
|
I find the 'pair programming' item most frightening, not because I'm scared of pair programming, but because of the prerequisites for that item to occur and its most likely outcome:- Engineering management (dominated by former mechanical engineers) is paying far too much attention to just how the golden goose lays those eggs.
- Management has decided we need to be 'Agile'.
- Management has hired a highly-paid consultant who recommends pair programming as a first step.
- The most productive members of the team are paired with new, 'already-agile' hires.
- The new hires haven't the slightest clue as to how their blithely refactoring those interfaces affects existing products.
- As an end result, all forward progress screeches to a halt, and the customer complaint data base balloons.
- The consultant blames existing team members for their poor adoption of the agile practices.
- All existing team members are terminated 'for cause', which means no termination benefits.
You can see the obvious outcome for the company. Since I would have been fired in the last step, I would not care.
Software Zen: delete this;
modified 1-Nov-16 9:40am.
|
|
|
|
|
While we use pair programming as a training technique, foisting it on developers is a pretty big mistake.
But your email points out the extreme level of division. Agile people who have ONLY ONE project to worry about. I would love to see them refactor some of the Cobol code where they have over 2,000 programs, all using and sharing the data structures. Some have not been recompiled in 7 years or more.
On the other hand, how do we know those old programs will recompile and work properly today?
This is the part of TDD/XP that I appreciate. Testability with full details/regression of prior issues.
<but they="" don't="" have="" to="" be="" so="" tightly="" coupled,="" and="" i="" think="" that="" will="" the="" "next="" new="" thing",="" lol="">
|
|
|
|
|
Next years project is to oversee (as an architect) a major java project.
The CEO decided a year ago the company would go Agile.
The java project is being outsourced to Hyderabad.
The project has been canned once already because they were reverse engineering a nightmare.
Why do I feel like I am watching a slow moving train wreck?
Thank the great Ghu I'm not a java developer and can refuse to get involved in the development.
Twill be interesting to see agile in action without having to partake!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Quote: "The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."
- The Wizardry Compiled_ by Rick Cook
Paulo Gomes
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
—Bill Gates
|
|
|
|
|
When my new boss thinks he's God's gift to software development, but in reality he's just a really good salesman.
|
|
|
|
|
Quote: but in reality he's just a really good salesman This was epic. But its not new. When he comes up and says i have architected the project, start developing it now and wont show his face till the last day of the demo.
Then, your hidden motives are to create an architecture of your own mysterious development. 
|
|
|
|
|
Unexpected support on weekend/odd hours and even worse when you have to handle/maintain someone else's written code.
Happy Coding...
|
|
|
|
|
Yep but that's the usual often happens with me. 
|
|
|
|