July 31, 2013 at 12:57 am
I think the first step is to instill a sense of ownership / pride in the developer in the product they develop. If you own it, are you happy with the product you have created?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 31, 2013 at 1:42 am
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.....
July 31, 2013 at 1:50 am
QA is necessary but the original problem is with the developers and how they are trained. Too often a developer's goal is to solve the problem; if rudimentary testing finds a path through the code that's job done. Developers, like testers, need to learn to think "how can what I write be broken" and cater for it. That's what makes the difference between an average developer and a good one. (I'm a developer)
July 31, 2013 at 1:55 am
I think the ownership comment hits the nail on the head.
When we moved to agile roles and responsibilities got blurred and initially things got missed because no-one was sure who owned it, who was responsible for it and who was supposed to do what.
Then there was failure to recognise that certain specialisms are not just jobs to be assigned but vocations. Being a DBA requires a mindset, being a tester requires a mindset, being a project manager requires a mindset.
Yes we can step beyond our own boundaries and multi-skill but we have to respect that things like testing are very real skills and disciplines and deserve respect.
I do wonder if the idea of a multi-skilled cross functional team has somehow resulted in an implementation of amorphous grey goo rather than best of breed.
If you have ever been privileged to work with a professional tester you will appreciate that they operate on a whole new level. They will ask questions of your product that you would never think to ask. My God it can be embarrassing!
The trick is in establishing and maintaining a good relationship with someone whose role will involve identifying faults in your pride and joy; someone who is going to say "my word you have made an ugly baby" but have the diplomacy not to follow it with "it takes after you"!:hehe:
July 31, 2013 at 5:55 am
My boss related a story about some software he was troubleshooting in a call center. I don't recall if he developed it, but every so often the entire system would lock up. Drove him batty until he narrowed it down to one particular employee.
When the guy got bored, he would click on a certain button rapidly to see how fast he could make it change colors! It effectively created an (unintentional) DoS attack.
I also personally experienced one of the classic desktop support issues. One girl called to say her computer was having problems. We discovered most of the files in the C: drive were missing (this is way back in the Win95 era). At first we suspected a virus of some kind, then she admitted she moved the files somewhere else because "it looked messy".
Which goes to show you never know the crazy things users will do. Taught me a valuable lesson in learning to identify people who were likely to do "the dumb things" and have them beta-test.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
July 31, 2013 at 7:00 am
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. 🙂
July 31, 2013 at 7:08 am
Who could argue against testing, right? You would be crucified. But I think a mentality of "let QA do the testing" undermines good development. I am often confronted by code written by others - even on my own team - that is shoddy, to say the least. Too often, developers crank out whatever (sort of) works and move on. I work hard to test my code as I am writing it. I stop and think, "Does this make sense? Is this the best approach?" That means it tends to take me longer to put something out, but it's not filled with half-broken garbage. I am constantly shocked by the quality of code that many developers release for testing. 90% of the bugs are obvious and should have been found during development.
My code is by no means perfect and I do need good testers to help me out. But they are finding the edge cases, the obscure things that weren't apparently obvious. It's an insult to good QA people (and a waste of their time and skills) to hand them garbage code. Like a writer who splashes out a first draft in one pass and then hands it into an editor. What are they going to say? The first QA tester should always be the developer.
July 31, 2013 at 7:19 am
Let's all back up a minute and think about the true source of the problem .... poorly written specifications (if the developer even got one at all). When more emphasis is placed on requirements gathering and the development of a specification with use case scenarios and process flow charts, the end product is not only better, but there is less project/scope creep as well. A well written specification not only provides the business rules to the developer, it also guides the QA staff in the development of a testing plan. Wait, did I say testing plan? Yes, I certainly did. How many QA staff out there actually develop one for a major project so that they don't forget to test anything? This one certainly does!
July 31, 2013 at 7:37 am
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.
July 31, 2013 at 7:46 am
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).
July 31, 2013 at 7:59 am
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.
July 31, 2013 at 8:02 am
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
July 31, 2013 at 8:25 am
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.
July 31, 2013 at 8:26 am
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.
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply