Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

Less QA? Expand / Collapse
Author
Message
Posted Wednesday, July 31, 2013 7:46 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, January 15, 2014 9:58 AM
Points: 5, Visits: 79
Re: poorly written specifications

Although I agree that clarity is vital, specifications can be misused as a crutch. More importantly, the developer(s) need a deep understanding of the business problem that they are crafting a solution for. Any developer that requires specifications that say, "Put this button here" will fail. There are a million little (but important) decisions that we as developers have to make on a constant basis.

The solution is to make developers a part of the business process. If business units treat us as hired guns, coming in to code exactly to their specifications ("Don't think, just code!"), misunderstandings and disconnects will abound, and you will spend forever caught in a unproductive testing and revision feedback loops.

So yes, clear specifications are important, but not as important on ongoing dialogue and a willingness by developers (and project managers) to roll up their sleeves, work to understand the business problem, and stop trying to just code to the specs (nothing more, nothing less).
Post #1479492
Posted Wednesday, July 31, 2013 7:59 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, September 20, 2013 7:00 AM
Points: 2, Visits: 6
You are absolutely correct. We've recently implemented a process where the QA person does all the requirements gathering and the writing of the specification (which includes a description of why the programming is needed ... what purpose will it fulfill). Once that is done, a meeting is held between management, the QA person who wrote the spec, and the developer who will be assigned the spec. The results of the meeting may require a spec adjustment, or more clarification. We encourage constant dialogue between the assigned QA and developer staff throughout the life of the project. This method has proven to be very successful for us, and has significantly reduced project cost.
Post #1479500
Posted Wednesday, July 31, 2013 8:02 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 7:07 AM
Points: 271, Visits: 822
Is it any wonder that people don't take pride or ownership anymore? I'd argue that the problem starts higher that either developers or QA. It oozes from the top down from a basic disrespect of how creative people work.

When I first started coding back in the Pleistocene, programming was seen as a creative art and (in the best workgroups) so was QA. I absolutely love working for a tough, smart QA person who can expose my sloppiness, (on those rare occasions when it occurs.) Good QA people don't think outside the box, they don't even see the box!

But somewhere along the way, universities began churning out people with 'IT management' degrees who have increasingly seen software development as a rules-driven straight engineering process with no room for extra thought, extra reviews, or extra questions. To them, programmers and QA people have become replaceable modules who only need to blindly follow all instructions from on high.

Agile is also part of the same problem when it blurs the roles and re-defines 'completion' to mean If it's running today, ship it!.


Sigerson

"No pressure, no diamonds." - Thomas Carlyle
Post #1479502
Posted Wednesday, July 31, 2013 8:25 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, June 20, 2014 8:23 AM
Points: 738, Visits: 1,305
Good article, Steve, and one that I can really relate to, being a developer myself. I've always worked in small shops (I'm currently working in the smallest shop I've ever worked in), so we don't have QA staff. We (all of 2 of us) wear multiple hats. I consider my testing abilities to be great, but the truth is probably more like I'm fair to good at best. I've never worked with anyone who has TDD experience. And it's never come up as a topic in my .NET user group. Once I applied for a test position, but didn't get the job. However, at the interview I did get the opinion that testing was looked down upon by the rest of the development staff. I tend to think that QA, and testers especially, are the red-headed step child that no one wants. It's a pity, because as you say we're left with buggy code.

On the other hand, look at the cadence of software release today! The single most important issue in the marketplace today is to get your product out ASAP, and then fix it once it's out there. If you're a week behind the competition, it's like you shouldn't even bother.

Lastly, I'd like to say that although testing is something that is taken for granted, I for one, would like to have some good old fashion training on it. In a user group or something like that. Now that I think of it, I don't call ever seeing testing as a main topic, in something like a New Horizons training course, or any other training groups out there. There's probably a Pluralsight video for it, but at least for me a video is great, so long as your particular probably is almost exactly like what's covered in the video.


Kindest Regards,

Rod
Connect with me on LinkedIn.
Post #1479507
Posted Wednesday, July 31, 2013 8:26 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, June 20, 2014 8:23 AM
Points: 738, Visits: 1,305
PhilipC (7/31/2013)
Has anyone noticed how vendor databases in general are getting worse and worse? It seems we're getting to an age where regardless of quality, it's just get the product out the door as quickly as possible.

The company I work for just purchased a product which landed with me to install the database, and what I find is a database with very few tables actually having primary keys, no indexes and after a big data load they wonder why the performance is shot to hell.....


I totally hear you! We've got a third party product, for scanning in signed documents, which we depend upon. Since they use SQL Server I decided to take a look at their database. Not one table had a primary key or index. They were all just flat files, for all intents and purposes. Now, in fairness to the company that made this product, recently I've noticed that they've cleaned up their act somewhat and have at least made primary keys in their tables. Nothing is related to anything else, but hey, they've at least got primary keys!


Kindest Regards,

Rod
Connect with me on LinkedIn.
Post #1479509
Posted Wednesday, July 31, 2013 9:39 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
PhilipC (7/31/2013)
Has anyone noticed how vendor databases in general are getting worse and worse? It seems we're getting to an age where regardless of quality, it's just get the product out the door as quickly as possible.

The company I work for just purchased a product which landed with me to install the database, and what I find is a database with very few tables actually having primary keys, no indexes and after a big data load they wonder why the performance is shot to hell.....


Not sure this is a change. I've worked with products based on SQL Server for 20+ years. I've seen plenty of this. What's distressing is things aren't getting better.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1479547
Posted Wednesday, July 31, 2013 9:42 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
OCTom (7/31/2013)
[quote] We still produce lots of software that takes too long to develope, costs too much, and often has too many bugs.[\quote]

What you're asking for Steve is impossible.

You can have it fast, cheap, and good. Pick two.



LOL, not sure I was asking for anything, but implying we should be doing better, and getting better at testing. Not sure we are.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1479548
Posted Wednesday, July 31, 2013 9:44 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
Brad Hurlbert (7/31/2013)
I concur with the idea that developers need continuing education and ownership. I also want to add the business principals. Too often, software development is treated as an expense meant to be kept as low as possible. Software developers? They get treated as if they are a little more than advanced accounting clerks. And the biggest mistake that management of any business can make is to be satisfied by the low-bar metric that "It works". I've raised attention to many senior management folks the lack of quality in the their code-base, their architecture and their testing. Only to be looked at as if I were making a mountain out of mole hill. Then they say something like "It works" so what is the problem?

In any case, there a many many factors contributing to low quality code and architectures. We definitely need to continue the pursuit of high quality in our code, regardless of those who only speak the words and implement no real quality control.


Good points, though I'd note that if you treat software development as some clerk, you'll get clerk level work. You don't need to treat developers as princes and princesses, but treat their work with a level of importance that's equivalent to how you'll feel if the software doesn't work well.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1479552
Posted Wednesday, July 31, 2013 10:07 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 10:07 AM
Points: 2,401, Visits: 1,484
Time for the morning ramble -

First off I am old-school. What I do is a reflection on me. It is not the specifications not the tool. Further it is not a product of them or those in accounting or Human resources, it is my product.

Second when it fails I do not point fingers at the OS or other new code nor the database. I own the problem. I find the problem and I either have one of the other staff address the problem or I fix it myself. And when the OS or other technology changes, my work needs to either have anticipated the change, be impervious to the change, or be changed to work on the new platform.

Third I remember the old TV add where a automobile break repair company said that they stand behind their product. They were openly criticized because if they really believed in what they were doing, they would stand in front of their product, and later they did as cars would drive right up to them and show that the breaks really worked. I need to stand in front of and behind my product. It is not my output but part of me. I created it and no one else can understand it without my insight. I need to make it work right.

Lastly - I believe that if I can trumpet my successes, I should also admit my failures. Not everything I have done has worked first time every time. And some things has had to be readdressed and redone. SO WHAT! Development is a series of controlled failures breaking potentially new ground on the way to a previously unachieved goal. By definition failure is part of the process of getting there. However, once you have achieved the goal, you should be able to develop a process that gets you there repeatedly without failure.

Parting word - When perfection is expected, the one who is expecting it of others is most often disappointed. When it is expected that one must work with a creator to achieve a level of success over time, the goals are often reached.

M.


Not all gray hairs are Dinosaurs!
Post #1479570
Posted Wednesday, July 31, 2013 10:42 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 7:54 AM
Points: 593, Visits: 751
Miles Neale (7/31/2013)
Time for the morning ramble -

First off I am old-school. What I do is a reflection on me. It is not the specifications not the tool. Further it is not a product of them or those in accounting or Human resources, it is my product.

Second when it fails I do not point fingers at the OS or other new code nor the database. I own the problem. I find the problem and I either have one of the other staff address the problem or I fix it myself. And when the OS or other technology changes, my work needs to either have anticipated the change, be impervious to the change, or be changed to work on the new platform.

Third I remember the old TV add where a automobile break repair company said that they stand behind their product. They were openly criticized because if they really believed in what they were doing, they would stand in front of their product, and later they did as cars would drive right up to them and show that the breaks really worked. I need to stand in front of and behind my product. It is not my output but part of me. I created it and no one else can understand it without my insight. I need to make it work right.

Lastly - I believe that if I can trumpet my successes, I should also admit my failures. Not everything I have done has worked first time every time. And some things has had to be readdressed and redone. SO WHAT! Development is a series of controlled failures breaking potentially new ground on the way to a previously unachieved goal. By definition failure is part of the process of getting there. However, once you have achieved the goal, you should be able to develop a process that gets you there repeatedly without failure.

Parting word - When perfection is expected, the one who is expecting it of others is most often disappointed. When it is expected that one must work with a creator to achieve a level of success over time, the goals are often reached.

M.


Well said Miles! I wish more companies were as patient as mine to let their employees learn from their mistakes.


Tony
------------------------------------
Are you suggesting coconuts migrate?
Post #1479598
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse