Can't ANYONE write good code anymore?

[Buckrub]

What the flying flip is wrong with these guys? EVERY SINGLE phone app, every downloaded computer program, every purchased piece of software, is written so poorly that every few seconds, one device or another is begging me to UPDATE IT!!

When I wrote code, we always tested it, went over every conceivable future potentiality, ensured we'd cover ALL bases........and yes, technology was changing as fast then as it is now......

I don't get it. I just simply don't. I am going to start charting how much of my day is spent updating programs that shoulda/coulda been written correctly in the first place!!!

[Thumper]

ONE word comes to mind .... curmudgeon!

[Buckrub]

Like you ain't on many things.

One word comes to mind for you.......CROTCHETY OLD GOAT....

:moon

[jb]

Just like cars today, it use to be back when the car companies would do thorough testing of new products before they would offer them to the public, now it's easier for the public to test the product and correct it through recalls.

[Thumper]

Like you ain't on many things.

One word comes to mind for you.......CROTCHETY OLD GOAT....

:moon

That's SIX words!

Crotch ... as in; I ought'a kick you in the CROTCH.
Et ... as in; I ET squirrel stew for supper last night.
Y ... as in; Y r u such a big ol' curmudgeon?

Old ... as in; Buckrub is OLD as dirt!

Go ... as in; With Bucky's bowel problems, he has to GO 10 times/day.
At ... as in; I'm in Florida, where you AT? ;)

[Buckrub]

You're an eclectic contrarian, sir.

[LJ3]

It's more about how code is developed these days. Agile or Scrum frameworks are replacing traditional SDLC frameworks. Gone are the days when a huge release was worked on for months and months, or years even. It's a shorter "sprint" approach where user requirements are finally acknowledged as a variable that changes pretty much all the friggin' time.

If you were around development in the old days, you certainly know this to be true. Never in the history of man has a large application deployment gone without changes in scope and rework having to be done, more money being spent and what is delivered in the end is rarely what was defined in the beginning.

The new frameworks address those realities and provide other value that I'm too tired to type out right now because I've been supporting AppDev pussies all day.

It has pros and cons but generally I think is much better approach. If they release a bug, they can usually patch it pretty damn fast.

In other news, I share your annoyance at the seemingly constant updates. But it's better than waiting a year for an app to be released that is no longer relevant by the time it hits the market.

[Buckrub]

Good perspective, Lenster.

Thank you.

[BarryBobPosthole]

'sprints' is what they call them. Its where IT is doing 40 yard dashes instead of of 440s. Thus they get smaller releases and theoretically fewer requirements and the end result is bite sized changes the user community can absord. What it really means is endless UAT, an IT team that can't see the finish line, and everything you try to do costs a million dollars.

Yes. i LOVE IT.

BKB

[Thumper]

I have no clue what persactly youse dufes are babbling about, but as far as the updates I'm familiar with are concerned, I have no problem with them. I leave my computer on 24/7 and have it set to automatically update every morning at 3:30 am (or sumpin' like that). As for my iPhone, I simply check off the updates in the evening when I put it on the charger and everything is good to go in the morning.

So, like I said, either Bucky is just an old curmudgeon who isn't happy unless there's sumpin' to bitch about ... or I have no clue what youse dufes are talkin' about. (prolly the latter) ;)

[Buckrub]

I see it as "Noticing the little things in life that need our attention and immediate repair".

[LJ3]

Hehehe... trying to support them with a traditional model with my infrastructure and engineering team has been difficult, I'll give you that. We've greatly reduced our costs, though. Our UAT has adapted really well to the sprints. Each development team has the required number of QA and UAt people on the team. That seems to be the key for us, anyway. Each part of the process HAS to have a member on the agile team at all times. it can't be like the old school business or QA analyst that "takes the requirements from the user and gives them to the engineers" You have be in there, with the team, every day. It's not a part time job any more. getting old school business people to accept that is very difficult.

<iframe width="560" height="315" src="http://www.youtube.com/embed/RAY27NU1Jog" frameborder="0" allowfullscreen></iframe>


I'm still trying to find a sweet spot to deliver what they need from my team, still ain't there yet.

The finish line is there, you just have to look down... it's not way out there anymore :)

[Buckrub]

A 'sprint' is fine if the product is planned to last nineteen minutes.

Otherwise.........not so much.

[BarryBobPosthole]

Ask Birddog about UAT amd you'll get a cussing. He's doing UAT on a HUGE project (broken into sprints of course) and they're working him six days a week 12 hours a day. That tough on an old guy like him. Our proble prolly isn't the same as yours. Our problem is that the old white box testing phase is gone so it goes right into UAT without it working. And I don't think the Agile methodology takes multiple systems very well into account. The issue we run into most isn't the base functionality but when there are so many multiple calls to other systems that requires other teams to get involved to completely test it, that never happens. So the UAT teams crunch through test case after test case and they all fail. Its hard to keep any momentum at all in that environment.
Anyway, I'm sure the concept works in some environments. We can't seem to hit the ground with our hat.
BKB