Jump to content

Software guys..............


maddmaxx

Recommended Posts

It’s amazing what code writers can do and stay employed. When I was in IT with a large corporation, we dreaded the “transparent upgrades” the software team would roll out. It always meant we had to be there before anyone else because we knew there would be panic calls of something wrong. 

Link to comment
Share on other sites

10 minutes ago, maddmaxx said:

If you released a major app on the national stage and it was so bad that it crashed the efforts of millions of people due to major coding errors would you expect to keep your job?

My job is to report the status of the product. If the powers to be overrule me in triage -- so be it. But it's on them.

Link to comment
Share on other sites

1 minute ago, Dottles said:

My job is to report the status of the product. If the powers to be overrule me in triage -- so be it. But it's on them.

As software developers know, you build a product over time and are always changing, improving, tweaking, etc., but it is the management making the go/no go decisions. 

Usually, when a product sucks or fails, there are many many many more likely suspects for the failure than the actual folks doing the coding and testing.

  • Heart 2
  • Awesome 1
Link to comment
Share on other sites

24 minutes ago, maddmaxx said:

If you released a major app on the national stage and it was so bad that it crashed the efforts of millions of people due to major coding errors would you expect to keep your job?

If I worked for Microsoft, I'd expect those millions of people to pay extra for Major App 2.0 and a raise from Microsoft for increasing revenue.

  • Heart 3
Link to comment
Share on other sites

31 minutes ago, maddmaxx said:

If you released a major app on the national stage and it was so bad that it crashed the efforts of millions of people due to major coding errors would you expect to keep your job?

If the 'major coding error' made it past UAT then wouldn't it be the testers fault that the buggy code was released into the wild?

Link to comment
Share on other sites

1 minute ago, Mr. Silly said:

If the 'major coding error' made it past UAT then wouldn't it be the testers fault that the buggy code was released into the wild?

That's a LOT of assumptions.

Way too many places along the path to success or failure to be able to lay blame at anybody's feet without knowing the full picture. 

I'm guessing this is the Iowa Caucus seeming debacle, and I could imagine a bunch of different full or partial contributors to the problems.  Usually, shitty requirements starts the problems, but after that, there are literally dozens of points of FUBAR possible - and many are not in the folks coding or testing hands.

Link to comment
Share on other sites

18 minutes ago, Mr. Silly said:

If the 'major coding error' made it past UAT then wouldn't it be the testers fault that the buggy code was released into the wild?

No. I've caught lots of stuff that was ignored. I've also seen my workload increase and my test resources shrink as well as time to release. And I've worked in orgs that developers believe throwing it over the wall and washing there hands is acceptable. As RE mentions, bugs are typically institutional.

  • Heart 1
Link to comment
Share on other sites

1 hour ago, maddmaxx said:

Utopia is what you make it.  Too many excuses aren't how it should be done.

My point is that you are for some strange reason trying - with no insight into their FULL software development cycle - to blame only one part of the "team".  VERY dopey and generally a reason why poor software gets released  - ie someone making a bad call that the software/hardware/widget/gadget/doodad is good to go.

Someone or many someones took the decision to release the software, and I can guarantee it wasn't a coder or a tester. And that's assuming there was a test team, which may be questionable.

  • Awesome 1
Link to comment
Share on other sites

2 hours ago, Mr. Silly said:

If the 'major coding error' made it past UAT then wouldn't it be the testers fault that the buggy code was released into the wild?

If it was tested properly. I once worked as a tester on a large US Post Office project. It was buggy as hell. I was told in April of that year to stop writing up issues, but put them on paper to fix later, as the software HAD to be released in June. I promptly quit that job as I had a bad feeling that I was going to get the blame. It failed badly.

  • Awesome 1
Link to comment
Share on other sites

6 minutes ago, JerrySTL said:

I was told in April of that year to stop writing up issues

Who told you to stop writing up issues? A guy writing code or a manager? It usually takes a manager to make that kind of colossal mistake :D  The guys doing the work are too busy trying to interpret vague requirements in a tight (highly optimistic) schedule.  The poor QA team usually get some bit of notional time to perform rigorous testing, but we all know what happens when reality sets in.

Link to comment
Share on other sites

There could be lots of issues totally unrelated to a programmer or group of programmers.  It could be faulty designs that led to failure under full load.  Or the load testing was improperly calculated and real life was different.  There could be integration issues that were cause by the failure of teams to communicate (caused by poor management or poor execution of inter-team disciplines).  This list could go on and on but I highly doubt the failure can be place at the feet of one or eve a couple of coders.

I blame the Russians.  Do not listen to the IDC.

  • Heart 1
Link to comment
Share on other sites

Just now, donkpow said:

Oh, slow. Lots of distractions. I set it up this morning to tweak it. Came in for lunch, took a nap, sat on the couch, broke the couch, fixed the couch, read some rubbish on the internet, ...

You are WAY more active than most folks here! Some here are happy to notice their transition from sleeping to napping and then back into sleeping.  If it wasn't for the brief interludes typing some nonsense here, many folks wouldn't come close to being considered "productive".

  • Haha 2
Link to comment
Share on other sites

1 hour ago, Razors Edge said:

My point is that you are for some strange reason trying - with no insight into their FULL software development cycle - to blame only one part of the "team".  VERY dopey and generally a reason why poor software gets released  - ie someone making a bad call that the software/hardware/widget/gadget/doodad is good to go.

Someone or many someones took the decision to release the software, and I can guarantee it wasn't a coder or a tester. And that's assuming there was a test team, which may be questionable.

 

1 hour ago, JerrySTL said:

If it was tested properly. I once worked as a tester on a large US Post Office project. It was buggy as hell. I was told in April of that year to stop writing up issues, but put them on paper to fix later, as the software HAD to be released in June. I promptly quit that job as I had a bad feeling that I was going to get the blame. It failed badly.

This is exactly right. If you just believe this is only a test issue, please let me know which company it is that believes this and I will show you failures. The tester cannot dictate release schedules. The tester cannot demand which bugs are worked on. Test plans are contracts between the test team, the development team, and the business. Nowadays the process is iterative and test plans are dismissed altogether. Is that my fault? No. We all have a stake in delivering high quality. To blame one team is old school military and government strategies. But if the company is avionics or telecommutions then they play by different rules. It's top down waterfall stuff.

  • Heart 1
Link to comment
Share on other sites

Just now, Razors Edge said:

You are WAY more active than most folks here! Some here are happy to notice their transition from sleeping to napping and then back into sleeping.  If it wasn't for the brief interludes typing some nonsense here, many folks wouldn't come close to being considered "productive".

I'm thinking about making some coffee. (He says in a deep southern drawl.)

  • Haha 1
Link to comment
Share on other sites

2 hours ago, Razors Edge said:

My point is that you are for some strange reason trying - with no insight into their FULL software development cycle - to blame only one part of the "team".  VERY dopey and generally a reason why poor software gets released  - ie someone making a bad call that the software/hardware/widget/gadget/doodad is good to go.

Someone or many someones took the decision to release the software, and I can guarantee it wasn't a coder or a tester. And that's assuming there was a test team, which may be questionable.

As the guy who designed and authored the 90's edition of the controlling software for Pratt and Whitney's test cells I think I have a very good handle on the Full Software Development cycle.  Good enough at least to have various aerospace companies to hire me as a consultant.  I will admit to not being a full time software guy, but rather the guy who merges mechanical design with the software to run it.

You?

Link to comment
Share on other sites

Just now, maddmaxx said:

As the guy who designed and authored the 90's edition of the controlling software for Pratt and Whitney's test cells I think I have a very good handle on the Full Software Development cycle.  

You?

Me and every one else here?  I don't think anyone except you is placing the blame on the guy(s) writing the code.  It's a process, and if you are fixated on one part, that's your issue, not ours.

Link to comment
Share on other sites

2 minutes ago, Razors Edge said:

Me and every one else here?  I don't think anyone except you is placing the blame on the guy(s) writing the code.  It's a process, and if you are fixated on one part, that's your issue, not ours.

It may not be their fault but coders far too often begin writing code before they or anyone has a good handle on what the program really is supposed to do.

Link to comment
Share on other sites

1 minute ago, maddmaxx said:

It may not be their fault but coders far too often begin writing code before they or anyone has a good handle on what the program really is supposed to do.

Ah, so it is likely there was some blame to go around?  Good to know.

Link to comment
Share on other sites

3 minutes ago, Razors Edge said:

Ah, so it is likely there was some blame to go around?  Good to know.

Yes.  The coders should have known better.  I don't know about your world, but in mine the coders aren't a room full of guys who do nothing but code.  They are hands on all of the program parameters.......which they often don't understand as well as they think they do.

What for example could you tell me about the needs of a program monitoring the position of a valve that has a limit switch on the open position and another on the closed position.  Hint, you're getting a head start as the programmers who first wrote this program thought that they could get by with just one switch.

Link to comment
Share on other sites

1 minute ago, maddmaxx said:

Yes.  The coders should have known better.  I don't know about your world, but in mine the coders aren't a room full of guys who do nothing but code.  They are hands on all of the program parameters.......which they often don't understand as well as they think they do.

What for example could you tell me about the needs of a program monitoring the position of a valve that has a limit switch on the open position and another on the closed position.  Hint, you're getting a head start as the programmers who first wrote this program thought that they could get by with just one switch.

Out of curiosity, which coder do you choose to make the release decision for you?  Blame that guy.

Link to comment
Share on other sites

1 minute ago, Razors Edge said:

Just point me in the direction of which software guy/gal you think should be losing his/her job today.  Then we'll be on the same page. 

Any or all.  You're the one who determined that a coding error was the fault of code writers only.  My experience is that coders often begin writing code before the program has been defined.  I also operate in a business model where the coders are not just coders but who are also the people who have to understand how the machinery works.  You didn't try to explain my valve example yet?  What are some important parameters that one might need to know and program for?

Link to comment
Share on other sites

1 hour ago, Razors Edge said:

Ah, so it is likely there was some blame to go around?  Good to know.

I saw a story in NYT that was partial blaming the poll workers not being able to use the app. Something about the generation that thought of remote TV controls as "clickers". Also poor internet at the schools & gyms. Ohh and now it was Hilary's team that F'd up

somewhere a MBA last his job today

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...