Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> Comments on: Episode 21: Real World Development http://herdingcode.com/?p=64 The Herding Code Podcast Fri, 10 Sep 2010 06:25:51 +0000 hourly 1 http://wordpress.org/?v=abc By: Scott Koon http://herdingcode.com/?p=64&cpage=1#comment-11733 Scott Koon Tue, 02 Mar 2010 15:53:07 +0000 http://herdingcode.com/?p=64#comment-11733 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 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

]]> By: Wayne Koorts http://herdingcode.com/?p=64&cpage=1#comment-11677 Wayne Koorts Sun, 28 Feb 2010 08:04:38 +0000 http://herdingcode.com/?p=64#comment-11677 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. 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.

]]> By: admin http://herdingcode.com/?p=64&cpage=1#comment-382 admin Sat, 18 Oct 2008 20:17:18 +0000 http://herdingcode.com/?p=64#comment-382 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 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

]]> By: Wynn http://herdingcode.com/?p=64&cpage=1#comment-381 Wynn Sat, 18 Oct 2008 16:21:52 +0000 http://herdingcode.com/?p=64#comment-381 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). 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).

]]> By: Ed McPadden http://herdingcode.com/?p=64&cpage=1#comment-349 Ed McPadden Mon, 13 Oct 2008 01:29:05 +0000 http://herdingcode.com/?p=64#comment-349 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) 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)

]]>