Reply
Wordsmith
doncr
Posts: 492
Registered: ‎12-29-2010
0 Kudos

Re: Not Just BN, Industry issue

One of the problems with software development is also one of it's greatest assets- it's relatively cheap to make code changes and push a patch out on the Internet. 

 

Because of this, you'll find management mistakenly hiring programmers (code spigots) instead of disciplined engineers.  In our increasingly ADHD throw-away society, there's more money to be made in being first, rather than best.  Instead of being good, you only need to be good enough, especially with consumer-level apps for platforms like a smartphone or tablet.

 

it's also rare that the engineer ends up being the person that also produces the end product, as is the case in software engineering. This actually enables the "spew code and see what sticks" mindset.  Call it "agile" or "iterative" or whatever the latest buzzword is, but that sort of thing would never fly in structural engineering.

 

Oh and speaking of structural engineering... For those of us that live in the Seattle area, we've just witnessed what happens when our state DoT structural engineers design a bridge foundation and cut corners.  That blunder is going to end up costing the taxpayers about $100M.  Looks like some engineers are going to be looking for work soon, but luckily for them there are lots of software jobs here and these guys have basically demonstrated they grok the software development process.  It's too bad you can't patch tons of concrete over the Internet.

 

 

 

Distinguished Bibliophile
bobstro
Posts: 3,521
Registered: ‎01-01-2012
0 Kudos

Re: Not Just BN, Industry issue

[ Edited ]

flyingtoastr wrote:

The promise of after-the-sale software updates is what changed it. Since companies can alter and fix and tweak and then release that to consumers, there's less of an onus to "get it done right before release". When software was distributed on physical media it would be incredibly expensive to patch, so they needed to get it working before they shipped.


I think you nailed it, FT. At least the beginnings of it. Back when a piece software was $65+ and shipped with media and a book, the cost of a do-over was huge. Now it's next to nothing. That's both a blessing and a curse, as Don has noted.

 

For a little phone app, no big deal. The problem is when a programmer moves from the lightweight stuff to serious stuff and brings those attitudes along.

 

I think the model of including your app (reader & library) along with OS updates and vice-versa compounds this. EVERY update is a big deal, with all sorts of potential to introduce problems.

Distinguished Correspondent
sparky_80
Posts: 89
Registered: ‎06-30-2012
0 Kudos

Re: Not Just BN, Industry issue


flyingtoastr wrote:

The promise of after-the-sale software updates is what changed it. Since companies can alter and fix and tweak and then release that to consumers, there's less of an onus to "get it done right before release". When software was distributed on physical media it would be incredibly expensive to patch, so they needed to get it working before they shipped.


 

I disagree. We've been able to do quick fixes for quite a while now.  I've been with the same software development company since 1997.  We were able to do immediate updates to web based applications since I started. 

 

For products that were shipped on physical media, the first thing we do is 'phone home' to see if there is an updated version.  Again, this is something that has been around for at least 15 years.

 

Poorly QA'd applications is a result of cost cutting.  Having developers do QA is dumb, but that hasn't stopped the bad project managers from requiring it.  

 

We are very proud of the software at our company.  We hardley ever have to release a patch or a bug fix version.  But we also employ nearly as many QA as developers.

 

 

Bibliophile
5ivedom
Posts: 3,544
Registered: ‎12-03-2011
0 Kudos

Re: Not Just BN, Industry issue

[ Edited ]

I think this is a very interesting discussion.

 

1) Ratio of QA to Dev, in my opinion, is a very good indicator of the quality of software you'll get.

 

We have a 2:3 ratio but it's still a struggle sometimes. Ideal for me would be 1:1.

 

I've heard people mention 1 QA for every 3 Developers for some companies and that just sounds wrong.

 

*****

 

2) When I lived in Seattle I heard of the whole 'Amazon developers do their own testing' thing and thought it an urban myth.

 

Perhaps that's why Amazon let's developers take in their dogs. So the developers can hug their dog anytime the QA+Dev dual work is killing their happiness.

 

*****

 

3) I've actually seen more of the 'very expensive to patch later' software situations in the last 15 years than of the digital, easy to fix type of things.

 

In enterprise (some experience there) it's just absolutely vital to not break the SLA so you just can't ship Beta level software.

 

I don't know. I have never really seen the whole promised 'quick fix' thing actually work. Perhaps it's because part of my experience was enterprise and part was with security software.

 

There was never ever a situation of 'we have a big bug, here's an easy fix we can quickly deliver'. There were always major headaches and nightmares for everyone and lots of overtime and stress.

 

Even if you discount the stress and pressure on everyone to find the fix and deliver it, you still lose a lot in terms of customer happiness and reputation.

 

I'll add one thing. I think it might be that I never saw the 'easy fix' because I worked mostly with very strong QA organizations. So there was always this feeling of 'let's do the fix, but let's not make it worse' and so it meant a very involved testing process.

 

I read about all the new web websites that have a model of 'ship it and fix it when it breaks' and it's a completely different mindset. Hard to get my head around that concept.

Distinguished Bibliophile
keriflur
Posts: 6,173
Registered: ‎01-05-2010
0 Kudos

Re: Not Just BN, Industry issue

Nope, not a myth.  I've found that QA is undervalued in the Seattle area as a whole, and that includes Microsoft.  (One of the hats I wear as a consultant is Test Lead.  Or, at least I did before moving here.) I find they also undervalue Business Analysts, so figuring out the actual user needs falls to the wayside also.

Distinguished Scribe
Omnigeek
Posts: 877
Registered: ‎01-25-2011

Re: Not Just BN, Industry issue


keriflur wrote:

Nope, not a myth.  I've found that QA is undervalued in the Seattle area as a whole, and that includes Microsoft.


 

 

That's not surprising.  I've rather felt Microsoft was one of the worst offenders of not QCing their product since DOS 3.0.  Bugs in their products seemed like wholesale violations of some of the most basic principles of software engineering that I studied in college (like checking boundary conditions for program inputs).

Currently reading: Destiny of the Republic, The Heritage of Shannara, Lonely Planet: Melbourne & Victoria