This sounds very intriguing, and not just because of the immediate problem I'm trying to solve- but I won't go into that for the moment.

I guess the big question is, how does QA validate the binding code? The notion that they may not be testing what they think they are testing due to a bug in the binding code is pretty scary.

Other less important questions- when are these BDD scripts created? I could see QA doing this while devs are working on the feature, meaning that there is a lot less strain on QA near the end of the sprint. Are you using TDD and this testing is supplemental? I've never really understood if BDD is supposed to replace or supplement TDD. It sound supplemental to me (TDD is design and unit testing, while BDD tests broader scenarios). How much developer time is required for the bindings? I assume this would lessen over time as you'll have coded some reusable pieces (use is logged in as admin, etc).

Sorry for all the questions- but this idea has real promise and I'd like to know as much as I can before bringing it up to our project manager (I will probably download specflow this weekend and attempt to generate some scenerios avainst an existing resource).

There's a couple of things that work here:

1. Coverage -- if you've got enough tests checking enough scenarios, gaps in the tests will tend to be fairly obvious. This is backed up by a certain amount of exploratory testing. It's not perfect: we had a bug in our tests for a couple of iterations before we noticed. Fortunately, the bug was only in the tests; real-world usage wouldn't have triggered it. If it had been a real-world bug, I'm fairly confident that it would have been spotted sooner.

2. Technically proficient QA. Our QA guys are probably marginal at actually writing the bindings, but they're perfectly happy to review them.

3. Code reviews. We have a rule that nothing is allowed to be checked in without being reviewed. Obviously, it's actually more like a guideline, but we're pretty good at following this rule. Pairing supplements this for the trickier bits of code.



This is exactly how we do it. And the lack of strain on QA at the end of the sprint/iteration is awesome to behold.



It's supplemental. Define behavior in BDD. It fails. Write unit tests (TDD) for those missing features, make those pass, refactor. We've tended to slack on the unit tests, which I think is hurting us slightly.

Here's a cool slide deck: http://www.slideshare.net/drumwurzel/getting-comfortable-with-bdd

You will require more dev time, but that's balanced by having the whole automated testing thing, and also frees your QA guys to do more in-depth exploratory testing. It also means that your QA have more time to get involved earlier, which means that everyone's on the same page for what you're building.

Writing the BDD tests properly is a bit of an art, and takes a while to get comfortable. That said, you can be fairly productive with it quite quickly.

Awesome- thanks for the info. I tried out specflow writing a few scenarios for a feature that I worked on recently- I'm already a huge fan. And darn it if I didn't find a small defect (one of those- "It won't happen in production, but conceptually it's not quite right" kinds of things).

One problem that we've been having is that the PM's great value to this project is she has more business knowledge of what we are building than anyone else. This has led to a great strain on her time as she tries to make sure she verifies absolutely everything we do and that there are no gaps in dev/QA's understanding of business logic. Executable specs would be an enormous benefit to her (at least I think so) because it would be easy to review QA's understanding of the problem we are trying to solve- and do it without requiring a demo or calling a meeting.

I'll admit that I am slightly proud that our app is organized well enough to really take advantage of this- that is that our business logic all exists server side so it can be verified without requiring the client. Individual modules of our code base may be difficult to work with, but the overall structure is very well done (imo). I'm also thinking about how we can use this client side as well- we have absolutely no automated regression testing because we burned about a month and a half trying to get Telerik's Silverlight automated testing tools working with very little success. This would let us test from the viewmodel down- I'm not sure if we could actually hook into the actual views or not. Either way- there's definitely a lot of potential here, and I'm glad this came up. I don't know if it will get us to two teams (it may- this might allow us to have a bank end/front end separation), but if not there's potential to alleviate a lot of other strain on the project.

Ok, BDD excitement aside, let me return to the original problem (which is that I spend a lot of time dealing with poorly written code by people on the team not implementing good coding practices). Assuming (for the moment) we cannot change the team sizes, is there any other advice? I know a lot has been given already (and I am truly, truly grateful)- but some of it is a bit over my pay grade.

The only thing I know we can do is that we absolutly can create a list of "Thou Shall" and "Thou Shall Not" coding rules. In fact, this is what my manager wants to do. IF we move foward with this, is there any advice on some good things to put on this list? My thinking thus far is

-Developers must write test for any piece of code that a) does not talk directly to external resources b) is in the view (xaml or code behind) c) is otherwise excused by a TA

-Developers will not check in code without corresponding unit tests unless excused by a TA

-Developers will not check in methods with more that 5 (totally pulling that number out of my nether region- is there a good number here?) control statements (If statements- loop statements, etc.) unless excused by a TA


That last one feels terrible, but how else can I quantify "Write modular code"? I actually don't mind long methods, as long as they don't have many control statements (that is, a 200 line method containing purely assignment statements doesn't bother me in the slightest).

Am I totally on the wrong track here? Is there another way to force developers who are writing difficult to maintian code into writing better code? Also, this doesn't really address the concept of complicated classes that are doing too much. I don't really have an answer for how to curb that, espcially since our ViewModel design is pretty messy, so implementations tend to be messy. Can't really fault people for that. Beyond that, we have some classes that contain tons of procedural code that have gotten pretty big, but I don't find them to be difficult to work in. If a class is just a container of procedural code, it's not that hard to figure out. It's when a class is actually an object with state that getting big makes it difficult to understand. So it's difficult to say "Classes must be less that xyz size". I suppose you could say "Classes that maintian state and are not ViewModels must be less than 300 lines of code" or something like that.

Finally, how do you enforce any of this? I doubt we can dock pay- but what if a developer continues to not write unit tests or big messy methods?

Add cyclic complexity as one of your continuous integration steps. If it's above a certain threshold, fail the build.

It is terrible. I suspect what you're trying to express is closer to minimizing nesting depth, rather than minimizing control statements. Having a number of control statements in a row isn't hard to follow, it's when the control statements are within control statements, within control statements.

But what Roger said... use cyclomatic complexity as your measure. I wouldn't suggest failing a build because the number is "too high", though, since you may have code that requires that complexity for some reason. It (along with all metrics) is more of a guideline, really, offering insight into areas of code that may be more prone to bugs, or are in need of refactoring.

That, and test coverage, are the two most useful metrics I've used.

I'm far from a professional developer, but maybe instead of raw numbers you could look at an increase in numbers. And then assign "blame" for those numbers. And then put up a leaderboard.

Maybe turning it into a little competition would help. I'm thinking more of bragging rights, though, than Cadillacs and steak knives.

That's actually the best use for metrics -- looking at changes over time. Raw numbers are meaningless without the context. Is a complexity of 10 good or bad? Well, it's good, if the rest of your software has complexity numbers in the 50s. It might be bad, if the rest of your software has complexity numbers in the low single digits. It might be good, if it's encapsulating a complex piece of business logic in a minimally atomic piece of code. It's worth noting if it doubled from the last time you collected metrics.

It's also a good way of collecting data on under-performing team-mates. Isolate change sets, note the complexity of the functions being touched, pre- and post-edit. Did it go up? By a lot? Are they consistently writing code with complexity metrics significantly higher than the project average, even taking into account those cases where the complexity is a necessity? Does the high-complexity code correspond to where you're finding all the bugs? It probably will (based on existing research), but if the bugs are in low-complexity code, that's a darn good indicator that someone is doing a sloppy job of testing.

Compare the numbers of people following the practice of TDD and writing short, modular methods, with those who aren't. All of a sudden, there's hard data to back up assertions that TDD and short, modular methods are a cornerstone of writing quality software, and it's no longer a subjective argument.

Yes- nested control statements are what I meant. I looked at some tools this weekend for evaluating cyclomatic complexity and that seems a good way to go.

I definitely like the idea of tracking trends rather than hard targets. This seems a lot more empowering than a "Thou Shall Not" list. Really good advice guys.

Also, I talked in depth with our two TAs about splitting into client and server teams and using specflow to help QA verify the back end teams work. They are both VERY positive about the idea and I think are going to push for it. Also, I introduced our two best QA to specflow and they are pretty excited at the concept.

My manager (the TA on our side) says he wishes he was involved in such a productive forum as this one. Thanks for all of the insight guys!

On a darker note, we just had to push back our release date, and the reason had nothing to do with anything in this thread. Our PO is NOT happy, but it's all above my pay grade. For inquiring minds, it appears like our best solution is to port the entire client to WPF, and I'm fronting the effort for the moment. It will be a fun Christmas this year, no doubt!

Next thing you know, he'll be wanting an empeg of his own.

I was really happy with the scrum process at SOE during the development of DC. One of the requirements we had was that there had to be an "in testing" column on our scrum boards. Any task that had a testable piece would then be moved into the testing column and sent to QA. A QA rep was then the only person who could move that scrum card out of testing and put it in finished. If the found a bug, it was addressed and fixed with the initial task. During early development, this worked decently to catch a number of bugs before engineers moved on to a new sprint.