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
When my boss look for possible existing solutions for a new problem/request from a customer...
Boss founds something that fits the needs (or he believes so), which means:
a: We have to adopt some external solution made in PHP/Python (no-one here really know that), and support it from now on...
b: We have to rewrite the solution by looking at the publicly available screenshots
Boss does not found anything, in which cases, he picks the most similar module we have in our applications (similar like elephant and mouse - both grey) and now we have to bend this module to server two purposes...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Just a couple of years ago, I arrived at my new job to find the following corporate culture:
1. The IT department had been beaten into submission, and was not guiding the company's tech direction at all.
2. A "business analyst" (self-proclaimed) working in the call center had been implementing his own "systems" written in MS Access. Most "reports" were actually editable query views.
3. All invoicing was done in spreadsheets, and there was no audit trail of who had been invoiced (or who had paid) for what.
4. Said "BA" had the last say on anything I wrote, and was terrified of automation, or any software published post 1998.
5. I had to code in VB6 and VBA, because the not-a-BA couldn't understand C#, and insisted on "approving" all my code.
6. I was forbidden to replace any of his rubbish, because "I was spoiling all his fun".
7. All users had admin access to the servers and the databases.
8. Health and safety insisted on a doorstop being used whenever anyone entered the server room, and then insisted we turn off the cooling system because there was too much noise when we had the door open.
Last month, the not-a-BA resigned, and my blood pressure is slowly returning to normal levels.
...you scare of "local Gods", who turn everything to be how he likes, despite common standards and best practices. Agree 100%!
But most scary thing is these clowns leave the job and spread everywhere how genius they were on position "Senior God of IT department" and asks for position a step (or two) above! And needless to say most of such "hell knows what" came from India after 2-weeks courses "PHP for complete idiots" being given gold stamped "certificate".