This week Jon leads a discussion of real world development. We talk about how our development practices in our jobs and personal projects match up with the way we're "supposed to be" developing. Topics:
- What are the non-negotiable practices that we always use on any code we write?
- Jon isn't always Test Driven. Does that make him a bad person?
- Where do code reuse and maintainability stack up when it comes to other real world priorities, like hard deadlines and short technology lifespans?
- Is there a place for "forms over data" development? How about System.DraggyDroppy?
Links
Download / Listen
Herding Code 21: Real World Development
[audio:http://herdingcode.com/wp-content/uploads/HerdingCode-0021-Real-World-Development.mp3]
Oct
10
This entry was posted
on Friday, October 10th, 2008 at 4:56 pmand is filed under discussion, podcast.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
5 Comments Episode 21: Real World Development
Ed McPadden
October 12th, 2008 at 6:29 pm
Enjoyed the show. I’ve been developing software (first C++ then C#) for a long time. I started out doing personal finance boxed software and have done work for large financial companies. I am very intrigued by TDD but in my career I have never come across anyone that is doing it. From what I read online it seems like everyone is doing it. You guys (esp. Kevin and Scott) seem to have lots of experience here. I’d really appreciate a show on TDD. Especially how you go about it on a new project. It seems like the kind of thing that if not done right could be a complete waste of time.
Also, maybe a discussion about the adoption of TDD as you’ve seen it and success stories. I think its odd that I haven’t come across anyone using it when I’ve worked at a considerable number of places.
Thanks guys and keep up that great work on this pod cast.
…Ed (@emcpadden)
Wynn
October 18th, 2008 at 9:21 am
I like your podcast, but not everyone working in a corporate/intranet environment are doing draggydroppy. i’ve listened to a few of your podcasts so far and a few times it was implied that corporate developers have less of a skillset. that is not always the case. a lot of corporate developers are highly skilled and are writing large scalable apps that require more than just “learn as you go, lets create hundreds of forms and drag and drop fields out and tie to the stupid dataadapter” skills. also, a lot of times we are stuck with limited time and limited resources just like everyone else, so we limit users to a set of standard browsers instead of allowing users to use anything they want (and for a lot of other reasons, including help desk support).
admin
October 18th, 2008 at 1:17 pm
Wynn, the point I was trying to make is that enterprise development is under a lot of pressures: time, budget, and sometimes a range of skill levels (senior architects to junior developers). Sometimes those pressures dictate that you leverage controls and other platform features that are geared towards rapid development. So what I was trying to say is that, well, it’s unrealistic to set the bar on developer skill and software sophistication such that a small intranet application requires dependency injection, persistence ignorance, etc.
I spent about half my development career in corporate development shops, and worked with a broad range of developers: really skilled and passionate developers, junior developers who were just learning the ropes, and 9-to-5ers who didn’t see the point of going beyond the minimum required (which included a ban against learning anything new). It’s also really hard to hire alpha-developers, especially under time and budget constraints. So some projects/systems will get more love and skill than others.
Maybe a show about the challenges of corporate development – with an appropriate guest – might make for a good followup show somewhere down the line.
- Jon
Wayne Koorts
February 28th, 2010 at 1:04 am
I particularly enjoyed your discussion about unit testing and TTD. An interesting insight I hadn’t thought of before was where one of you (sorry, I don’t know the voices yet :( ) mentioned a positive side effect of unit testing being that when you write code with unit testing in mind, i.e. planning to write tests for it, you often end up with a better piece of code.
Admittedly I’m not a huge unit tester in my personal projects (usually quite small anyway) but that side effect will make me think again in future. I’m really surprised that it isn’t brought up more often in discussion of unit testing.
Scott Koon
March 2nd, 2010 at 8:53 am
Wayne,
There is a specific development methodology called TDD that deals with the particular case of driving the design of your code by writing unit tests first, one at a time, then writing code that will make the test pass. If you aren’t already familiar with it, I’d suggest looking into it and trying it out on your own code.
Here are a few links to get started.
http://www.agiledata.org/essays/tdd.html
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
RSS feed for comments on this post · TrackBack URI
Leave a Reply