what's going on with the quality of .net shops?

[Justin Collum]

OK, I'm looking for a new job. I'd prefer to find a job that doesn't suck. The bar is fairly low: 

- preferably not TFS for source control -- because of it's poor code re-use story and its propensity to get managers drunk with 'you must fill out all the TPS reports' style development

- testing; 50% coverage on unit tests would be acceptable 

- biz logic doesn't go in the database if at all possible

- CI -- goes with testing, hand in hand 

- look at all solutions to a problem instead of picking the one that Microsoft made by default

These are things that I think of when I separate the good from the bad and ugly. There's nothing on that list about being environment-aware, functional testing, automated deployments with roll forward/back, IOC / DI / Mocking. 

And yet, this list, simple as it is, practically puts me in the primadonna category. This makes me sad. Out of the last 4 places I've worked, only one would meet that list. Of the jobs that I've been looking at lately, only one meets that list. Is the typical .net dev not aware of the things that you do to build software well? Are we really terrible at selling these things to management? Are these things of such dubious value that maybe they aren't worth it at all? 

[Craig Wagner]

The problem is that most shops are trying to get a product to market, not do textbook perfect development. I'm not the biggest TFS fan in the world, but if that's what a shop wants to use, meh, whatever. I could probably name ten things more important to me about an environment than the VCS they are using. Then again, everyone has different priorities in life, so it's certainly not a case of one of us is right and the other is wrong.

--
Craig Wagner
"An expert is someone who is one page ahead of you in the instruction manual."

[Justin Collum]

Oh boy, that first sentence will spark some debate. 

[Troy Howard]

I'm about to do a blog post why the dichotomy that sentence presents
is false. I'll leave you with this one thought -- "the best
professional development practices are those that generate business
value most efficiently".

Thanks,
Troy

[Tom Denny]

- biz logic doesn't go in the database if at all possible

 

This always seems to be a debate and I hear good reasons for both.  Has the community settled the score on biz  logic in the database vs code or is it still a holy war?  I’m not asking to start a debate in altdotnet but rather for my own education in case biz logic in code has been settled on as being the best practice.  It’s certainly what I prefer too.

 

Sorry I can’t answer your question and comment on the PDX .NET shop scene.  I seem to do most of my work in the Seattle area.

 

-Tom

[Troy Howard]

Tom: Not sure about the rest of the world, but I've settled on that,
for sure. Databases should be used for storage and retrieval of opaque
data. Reusable code libraries hold business logic.

-T

[Adron Hall]

Yeah, I was going to say, if anything - the problem is exactly the text book development. The "follow Microsoft" way and "Waterfall" approach is what has landed shops, and .NET specifically, on the declining end of technology right now. But I digress, the fact is - agile, lean, etc & the implementation of clean process and practice is EXACTLY what gets high quality good product shipped. Not doing those things is what causes the whole problem and idea of "we have to hurry and ship a product so we're going to cut corners, not worry about doing things right, and we'll get it out the door faster and to market and we'll fix it later and ... and. .. and ..."  (beware, I might ruffle some feathers now)

that's bullshit.

The entire "don't worry about it now we'll worry about doing it good later" slows down development over time (usually takes no more than 2-3 weeks to make team "don't worry we'll do it later" way slow then the "agile/lean/SOLID/testing" team. I've seen it a dozen times, and yes, I've had the crazy lucky fortune of working with amazing agile/lean/fast teams that produce extremely high quality software. I won't attest to being a good developer, but in an environment with pairing, testing, CI + good process, I and anyone is 10x that of a developer on a team that doesn't do that. Without discipline and continuous learning, CI, testing, etc... the team falls behind, stress adds up, and then people write books like "Mythic Man Month" and "Death March".  :(

...and that sucks.

I'm not saying people are bad, or developers are bad for not working toward a good process, I'm just saying you're working too hard and doing too little over time. I still haven't seen a team that can touch a lean/agile pairing team. Literally the difference is what Joel Spoelsky talks about - the 10x or even 100x multiplier. I'd love for everyone to experience a truly great team like that, but we all have to fight the good fight in environments and not lose our passion and love of what we do...

...anyway I'm done ranting. The idea that "we gotta hurry and ship and can't do things good/well/right/cleanly/SOLID/smart" makes it harder on ALL of us trying to make environments better.

Anyway, I'm going to be working on some workshops that might quell some of this ideal (the let's not do things right ideal) and how to do things better, faster, cleaner, smarter without killing myself and still getting home at 5pm (or whenever) and seeing my wife/gf/bf/kids/family and not killing myself at work.

Cheers!  Hope to see everybody at the next ALT.NET meetup, workshop, hackathon, or what not!  Happy coding...

:D

--

Adron B Hall

Tech Blog: http://compositecode.com

About Me: http://compositecode.com/about

Twitter: http://www.twitter.com/adron

[Justin Collum]

This. Databases are terrible at logic. My current app has zero logic in the database -- mongodb doesn't really do that afaik although I think it's technically possible. Database logic is often much harder to debug in the future when you have no idea why you wrote that strange sql proc the way you did. That's been my experience. 

On Thu, Feb 16, 2012 at 3:05 PM, Troy Howard <thow...@gmail.com> wrote:

[Justin Collum]

I made a graph that illustrates the need for do it right instead of fix it later:  

http://imgur.com/KlEBv

Point is, if you just rush to get it out the door the next guy who comes along in six months and tries to fix your bugs has no freakin clue what you were doing. We all know that documentation is typically bad -- and why should it be good when you can write tests that document your code as well as test it?