Imagine a program like an anthill. For the last 25 years countless ants have been whipped through tight schedules. There is no docmentation and no architect. Every ant has to insticvely know what to do without any additional information and finish assignments on time. Speaking of the assignments: They are usually a handful of lines out of context that might as well read 'Do something, ant!'. Why waste time with giving the ants any details about what you want them to do?
I have worked in such a place and left because I'm not a good ant. From my observation, this anthill mentality is common in connection with Visual Basic. The anthills very often are old projects that started out with Access or VB6 and kept their good old practices for decades. When I hear something like that in an interview, the whole thing is over for me.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
I've worked in one such place in the past, and it's not a nice experience. Workplaces like that are so common that it's a scary thought. You don't realize what's going on until you're being whipped around, "doing something" there. If only there was a way for us to know if the place is an anthill before we could accept their offer.
When I hear something like that in an interview, the whole thing is over for me.
Whereas my most lucrative contracts in the 90s were these. Power user builds a pile of spaghetti in access, does the job, sort of. The boss decides to extend it to a full on production system with multiuser access and get a professional in, me.
I instantly trot out ms own words that access is s single use tool and scream rewrite.
Never underestimate the power of human stupidity
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...
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.
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