Corey Coogan

Python, .Net, C#, ASP.NET MVC, Architecture and Design

  • Subscribe

  • Archives

  • Blog Stats

    • 110,056 hits
  • Meta

Archive for the ‘Developer Life’ Category

Get the most from O’Reilly Books

Posted by coreycoogan on March 10, 2011


I love technical books and have purchased a fair amount from Manning, who gives a free eBook edition with their print books. I also like O’Reilly books and have purchased hard-copy books from their website in the past. Now that I have an iPad, I like the idea of having the books available to read on it, but some technical books are better suited to print. Having to flip through several pages to see a code sample can really become distracting.

I recently went to purchase some books from O’Reilly (3/9/2011) and they were having a buy 2 get 1 free deal. I tried to buy the print/eBook bundles and realized I couldn’t combine the “bundle” offer with the Buy Two promotion. Then it occurred to me that the bundle is unnecessary.

If there are any promotions happening on O’Reilly, ALWAYS take it over the bundle. NEVER take the bundle over any other promotion. The reason? Once you have a print book, you can go back to O’Reilly’s website and get the eBook for $4.99 – anytime. Now you get the bundle AND the current promotion.

Advertisements

Posted in Developer Life | Tagged: , , , | Comments Off on Get the most from O’Reilly Books

Is Developing Software Hard Work?

Posted by coreycoogan on September 24, 2010


I got to thinking about this a couple months ago as I sat in my chair pondering what a pain it was to accomplish some task I was working on.  There was a lot to do and I thought briefly to myself, “this is hard work”.  It was brief because I immediately sat back and enjoyed a small chuckle.  Can I honestly say that developing software is “hard” work?

Working Hard for Real

Many of friends from back home are in the trades – carpenters, electricians, plumbers, landscapers.  If they heard me describe anything I do in my profession as hard work, I’d probably get punched in the teeth, perhaps deservedly so.  When one of these guys has a day of hard work, it means breaking their back, spending thousands of calories, excreting gallons of sweat.  Sometimes they work so hard they even hurt themselves, but pick up the pieces and come back for more the next day.

My Kind of Working Hard

Now compare that to what I do.  When I am really working hard, would anyone be able to tell?  Could someone stop by my cube one day when I’m doing something easy and another day when I’m doing something hard and be able to tell the difference?  Would they be able to comment at the water cooler, “I just stopped by Corey’s cube and he is working really hard”.  I think not.

Often times working hard in the software profession is associated with the number of hours being worked.  I would agree, that this can be very difficult and the signs of this kind of hard work can certainly be visible to the naked eye.  For the purpose of this post, I’m talking about a regular 8 hours work day.

Thinking is Work

Back to my friends in the trades for a moment.  They would find it hysterical to hear me come home and tell the wife, “I’m tired…I worked very hard today.  Will you rub my fingers?”. Worked hard doing what?  Sitting on my ass?  Pushing buttons?  Wiggling my mouse around?  The truth is, yes, all of the above.  Hard work is a relative term.

For starters, let’s look at the definition of work:

sustained physical or mental effort to overcome obstacles and achieve an objective or result

Notice the word mental?  So we’re covered from a semantics standpoint.  Thinking actually is work – by definition!  If we go a little further, we find that there’s science that shows our brains consume quite a bit of energy.  The more we think, the more energy our brain needs.  This is confirmed by the fact that when we as humans stimulate our brains, we even get very hungry (which explains a lot about the typical IT break room and our physique as an industry).  If we’re consuming more energy and getting hungry, it must be hard work.

What does this Mean?

Great, so I now I know the harder I think, the harder I work.  What does this mean?  Do we as software developers ever take the easy way out because the alternative is so exhausting?  Probably not.  My gut tells me it’s more likely due to laziness than anything else. Sure, sometimes the situation demands that we cut corners, but other times there’s no real good excuse.

It was Vince Lombardi who said:

The only place success comes before work is in the dictionary.

I say we embrace hard work.  If we are going to sit on our butts for eight hours pushing buttons, we might as well make them count.

Posted in Developer Life | Tagged: , | Comments Off on Is Developing Software Hard Work?

Good Developers Know When to Write Bad Code

Posted by coreycoogan on September 22, 2010


I read a blog post last week that stated plainly if you “knowingly create a bad design or write bad code”, then you are a bad developer. The post went on to list 4 criteria that must be followed if you break this rule that would save an offender from earning the “Bad Developer” badge of shame.  (UPDATE: I misquoted.  The post actually said “one or more of the following)

  1. Get upset because they know they are writing less than perfect code/design.
  2. Leave a comment stating why the code/design was done in this factor.
  3. Add a ToDo for refactoring later.
  4. Will do the imperfect code/design in such a way that the refactoring effort will require less effort.

I read this post and had to disagree with such a dogmatic, black-and-white view. So here’s my take on the whole thing, breaking it down as simply as possible.

  • Time is finite.
  • Resources are finite.
  • Requirements are seemingly infinite.
  • Deadlines exist, sometimes arbitrarily and other times for real reasons like market pressures or legal diligence.
  • To meet deadlines when you are in the hole there are 2 options:
    – Cut features and scope.
    – Cut corners.
  • Sometimes features and scope can’t be cut (see Deadlines).
  • Some tasks require commodity code – simple crud forms for updating contact information for example.
  • Some tasks require specialization code – getting to the meat of the domain to add real value.
  • Many clients, who are paying the bills, don’t care about the commodity code’s design principles as much as they care about their deadlines and commitments.
  • Refactoring takes time, and given that time is finite, must be prioritized from highest ROI to lowest ROI.
  • When commodity code is poorly written but works just fine and causes zero friction, choosing to refactor it over specialty code can come with a hefty opportunity cost

Given this information, I say that a person can still be a good developer even if they knowingly write bad code. To me, a good developer knows when to write bad code and where to focus their time and energy.  In a perfect world, this would never happen – we would always do things the best way.  Obviously this isn’t reality and sometimes sacrifices have to be made. I believe that the good developer understands this and knows to sacrifice that which offers little value for that which offers great value.

Nobody is going to lose in the market because their “contact us” form is saving to the database in the code-behind. But choosing to devote an hour “doing it right” that could be spent refining the domain model or refactoring real friction points that cause actual pain can come at a high price. Like the old saying goes – Good, Fast or Cheap… pick any two.

Posted in Business, Developer Life | 5 Comments »

How to Give Advice Online

Posted by coreycoogan on September 16, 2010


We’ve all be there – stuck with some problem and the solution won’t reveal itself no matter how much we search.  It’s at this point that I turn my sights towards forums and user groups to try and get advice from the online community.  This can be Stack Overflow, a topic specific Google Group or a well known blog or forum site like Microsoft Social.

Side Note

It’s laughable to see how many people actually turn to the community for help before even attempting to figure things out themselves.  Ayende wrote about his frustrations on the topic, so please don’t be that person.  I digress…

I try to write my question to be as complete as possible.  I want to include everything I think someone would need to help me, fearing that if I leave something out the person who has the answer and was just willing to share it with me is now gone forever, helping someone else who wrote a more complete question.  The key is not to put too much information in the question.  I don’t want to scare anyone away by showing them 5000 lines of code when they open that sucker up.  So I try and find just the right balance and give disclaimers that some things are left out.

Enough setup, now for the crux of this post – "How to Give Advice Online", which could have also been titled "Don’t be a Dick when Giving Advice Online".  So often, the people that choose to answer questions commit one or more of the following dick behaviors:

  • Nitpick at unimportant details, like “you should close your connection” or “you should catch that exception”.
  • Make assumptions about the code that’s left out or the entire context of the problem, usually supporting the preconceived notion that they are smart and you are stupid.
  • Belittle, make fun and/or talk down to you during every exchange.
  • Give short, one-line solutions with no detail that are of little or no use and most certainly leave many a solution seeker more confused then they were when they started.  If you are going to throw someone a bone, spend the extra 60 seconds and at least make it complete enough to get the reader started in the right direction.

When I get these types of responses, I really try to remain patient.  It’s hard to resist the urge to stoop to their level and let things turn into a cat fight.  That’s just a waste of time and it’s unprofessional.  Not to mention there will be a permanent record of your childish behavior available for anyone who searches your name for all eternity.

I’ve read that people don’t act this way in the Ruby community, but it runs rampant in the .NET developer community.  Are .NET developers so arrogant and full of themselves that they believe they can treat people like crap?  What created this culture?  Very perplexing indeed.  The best I can do is try not to perpetuate this behavior and keep the stereotype going.

If you wish to donate some of your time and give free advice online, do it for the right reasons.  Don’t use it as an opportunity to make people feel stupid so you can feel superior.  Just be patient and share what you know.  Everybody needs help at some point, so think about how you’d you’d feel if you were given the response you’re writing.  If a question seems exceedingly stupid or you have a beef with the person asking it, move on. Like an offensive television or radio program – you can always turn the channel.  Put simply, don’t be a dick.

Posted in Developer Life | Tagged: , , | 2 Comments »

What does a Proof of Concept Really Prove?

Posted by coreycoogan on February 23, 2010


The company where I’m working right now likes to invest resources in Proof of Concept, or POC, projects.  The intent is admirable enough – prove that a concept/process/technology/etc. works by spiking some small portion of it and evaluating the results.

This sound really great in theory.  But if it was all gravy I wouldn’t be writing this post.  So here’s the rub – it has to be crystal clear exactly what is being proved.  If management is vague and just wants to see some documents or a demo, the risk in moving from POC to a production project becomes very high.

Let’s look at an example.  A project that I’m involved in right now is proving that legacy code can be taken from the outdated, purchased system with a proprietary-language and migrate core functionality to .NET – specifically WCF services.  Sounds simple enough, right?

The code in the existing system is a tangled mess, as one might expect, and all the logic is buried in the 3GL-type forms.  The database is also a rat’s nest and the converted code must use the legacy database.

The project is moving along and things are working, but an all too common dismissal for the quality of code that’s being written is “hey, it’s POC code”, which leads me to the point of this post.

Because the goal of this POC is only to see that it is possible to move legacy code to C# on WCF, it’s acceptable to the team that the code being written is a house of cards.  It is so brittle and hard to test that the smallest change could send it tumbling down.  My worst fear, however, is the possibility that a number of bugs and issues that result from a change could go undetected.

I don’t believe, in this example, that the concept is truly getting proved.  By not specifying that the project should prove the concept in a manageable way, following established practices for creating highly cohesive and loosely coupled code that is testable and continuously integrated with automated testing, the project sponsors have essentially said “build a house of cards” – hence the attitude that quality doesn’t matter because it’s just POC code. 

It’s my opinion that if one wants to prove a concept like the one I’ve been talking about, it has to be proven to be a viable solution in some real world capacity.  At the end of the project, the POC may be deemed a success but few will know if it is actually possible to build with a sense of confidence and stability.  The other angle is that management may expect that since the POC has already been completed, it shouldn’t take much more time to get it ready for prime-time, which is this case would be a fantasy.

In conclusion, when drafting POC project document, make sure to specify some degree of real-world expectations.  Build in the extra time to ensure that the concept can be built to withstand the pressures of real-world change.  Otherwise, you may not know the truth until you’ve either deployed a fragile system or found yourself sinking more resources into a project than you ever would have expected. This may not be applicable to the smaller projects, but for larger ones, I think it’s worth the investment.

Posted in Consulting, Developer Life, Software Management | Tagged: , , , , | Comments Off on What does a Proof of Concept Really Prove?

Eggheads, Elite, Shills and the Mainstream

Posted by coreycoogan on February 12, 2010


Scott Bellware, a once prominent member of the Alt.Net community before seemingly denouncing it sometime last year, has been very busy lately with some interesting and thought-provoking posts.  True to his usual form, you may want to keep a dictionary handy while reading.

In his post, How Mainstream Lost Software, Scott really said some things that hit home for me.  He talks about Eggheads in the following way:

Eggheads write and speak for other eggheads. The language they chose and the names given to design principles, as well as practices and patterns are stimulating to other eggheads and yet utterly obstructive to the other part of the software development population. When you measure the Egghead population against the mainstream population, the Egghead population doesn’t appear to be much more than a rounding error. There’s a lot of work to do, and we can do it much better.

Eggheads preach to the choir, and this is often so stimulating that they never leave the echo chamber. They don’t learn how to reach the mainstream. They hope that the people they do reach will somehow reach the mainstream, but those people usually end up emulating their egghead heros and become eggheads themselves. The circle expands slightly, but not merely enough to have the meaningful effect on software development productivity that their knowledge and understanding should already have had.

The other end of the spectrum is who he called Shills.  It takes only one meaningful sentence to convey what a Shill is:

Shills convince the mainstream to buy snake oil solutions to problems that could be easily solved with plain old soap and water.

So why did all this hit home?  The fact is, I’m an aspiring Egghead.  I absolutely love this stuff and am passionate about all things Egghead.  I work all day.  I work at night.  When I’m not working, I’m thinking about this stuff.  When I’m not thinking about it, I’m reading about it and wondering how I can improve my craft.  I try to emulate my Egghead heroes like Jeremy D. Miller, Ayende Rahien, Udi Dahan and many others.  I know I’m not even on the same planet and probably never will be, but I’ll never stop trying.

Scott says that people who really care about this stuff are nothing more than “a rounding error” compared with the mainstream development community, who has bought into what the Shills are selling.  I see it all the time.  “Why write unit tests first, or even by hand, when I have a wizard to generate them for me when I’m done?”.  “Why write my own decoupled, testable authentication scheme when I have the AspNetMembershipProvider?”.  It’s tough to win those debates because this is just not how most people understand things.

The impending doom of the Northeast WI Alt.Net User Group is what really brought this home.  It’s not officially over yet, but I was very surprised to find out how very little of the local population is in learning about things NOT mainstream Microsoft. I advocated the group to almost every developer I met but nobody ever showed any interest.  They show up at the INETA sponsored .NET User Group to learn about SharePoint and Silverlight RIA, but not Alt.net.  In my opinion, we were talking and learning about things that could be implemented right away to.  Things that had immediate benefit.  Why wouldn’t this interest people?

Scott Felder covered NServiceBus to an audience of 5.  I prepared a presentation on the Spark View Engine, which was supposed to be for an audience of 7.  Unfortunately only one person was actually going to come so I called him from the parking lot to let him know not to bother.  Other topics were going to include SRP/S.O.L.I.D., StructureMap, S#arpArchitecture, NHibernate and so much more.  The fact is, people just weren’t interested.

There was a bunch of discussion on our group about marketing and branding to generate interest, but it honestly seems like too much work.  I am a very busy person and time is so precious to me that it’s really hard to justify investing my time and energy into getting people interested in improving their craft.  We are in charge of our own path as developers – nobody else.  If they aren’t willing or interested in seeing what else is out there, it’s their loss, right?   Right?

So that’s the nerve that was touched.  Scott’s closing words included this:

What’s needed is a new generation of productivity missionaries who are willing to master the field of knowledge and are willing to learn to connect with the mainstream.

Again, I am not claiming to be elite or even in the top 50%, but I do admit to understanding a lot of this stuff.  Reading his post makes me feel a little guilty for wanting to bail on the Alt.Net user group.  It really made me look at that decision and reflect on the current state of the mainstream development community and ask myself if I’m happy with where things are.  The answer is no.  It takes too much energy to get people to even consider possibilities beyond 3 Tier architectures with so-called BLL’s that act as a pass-through to a DAL.  I don’t want to explain why breaking a God class down into 10 separate classes in the name of SRP really isn’t “a lot of extra work”.  Yes, IoC containers use reflection, but most of it gets done upfront and you have to consider everything you get… etc…

Thanks Scott for giving me more to think about.

Posted in Alt.Net, Consulting, Developer Life | Tagged: , , , | Comments Off on Eggheads, Elite, Shills and the Mainstream

Passion in Software Development

Posted by coreycoogan on July 22, 2009


I’ve been in the IT field since 1995, when I had my first internship with Ford Motor Company.  I didn’t do a whole lot that first year, where I worked on a help desk team, but I did manage to glean a few gems.  More recently, however, I was a Development Manager for over for 4 years and then moved to consulting where I’ve been for just over a year.

Through this experience I’ve worked with many different people and interviewed, and sometimes hired, many others.  The one quality that I’ve always searched for in people is the rare and elusive Passion.  Passion is quality that everyone has in them, although it may remain untapped until the person discovers what their passion truly is.  I recall an MSDN article I read a while back about how Microsoft looks for passion in people, even if it’s beyond the technical realm.  Although having passion about anything is better than no passion at all, I am still biased towards software development and IT when it comes to the teams I am surrounded by.  That’s not to say that one can’t have multiple passions, as I am very passionate about my wife and children, but I think my love for being a developer helps give me an edge.

Qualities of an Un-passionate Developer

So what are the qualities or criteria of a passionate Software Developer?  I think it goes without saying that true passion is very easy to spot without some list of criteria.  What might be easier is to go the other way and discuss the qualities I see in most Developers who aren’t passionate.

It’s obvious that there are many people who get into this field as a means of making a decent living.  For these people, developing software is merely a job and devoting any time outside of their 8 – 5 workday towards the field seem ludicrous.  They don’t subscribe to blogs and read very little magazines or books if any at all.  They depend on their passionate co-workers and leaders to teach them about what’s new and the latest techniques for doing things.  These are the people who nod with a blank look on their face when you talk about topics like Design Patterns, IoC, SOLID, CI, DSL’s and other hot issues in the development community.

A real-world example of this came from a person who was trying to code against some specifications that included Dependency Injection, several design patterns and some unit testing sprinkled in.  When I commented on how unhappy this person looked, the reply was that he liked doing the easy stuff that was in his comfort zone, but he was doubting the choice of a career where he would have to read and keep learning new stuff – “I went to college so I wouldn’t have to do that anymore”.

I’m not saying that there’s anything wrong with this attitude and often times certain projects or companies need bodies that are comfortable just doing what they are told to do.  Many people are content following a standard set of procedures and doing just enough to get by.  They are not concerned with being a software craftsman and if the code they write is un-maintainable and hard to test, the company will just unknowingly pay the price with longer development cycles the next time.

Spreading the Love

I believe that many times there is a passionate developer locked inside the people I described above.  There could be many reasons why their passion remains caged, but the 2 most obvious that come to mind are the restrictions in their job that prevent them from spreading their wings and simply getting too comfortable in what they are doing.

So what can we, the passionate, do to spread our love and joy for our craft?  I think there’s a few tactics that are worth exploring.

  1. Keep Talking – Passion is infectious and the more you keep talking about the cool stuff you’re learning or the latest project or experiment you are into the more likely your passion is to catch on.  Perhaps sharing your sense of accomplishment and/or enthusiasm will pique their interest in obtaining that same feeling.
  2. Lunch and Learn – Brown bag sessions and lunch and learns are a great way to share new stuff with your team.  It’s not enough, though, just to present.  Getting the whole team engaged by rotating presentation responsibilities is a great way to get people to spend some personal time learning about topics, tools and tactics that can benefit everyone.  Perhaps getting in the groove of learning will result in more.
  3. Get them involved – Solicit volunteers to help with any side projects you may be working on.  Volunteer on an open source project and work as a team to fix small bugs or take on small feature requests.
  4. Share heroes, books, articles – If you have some heroes that inspire you, share that with your teams.  Start a book club or send links to articles and inform that you’ll be discussing at your next meeting.  Share your RSS feeds and talk about the latest posts that interested you.  The Google Reader allows you to share your feeds either individually or from within your categories.  Here’s my feed as an example.
  5. Assign “Fun” Tasks – In even the most mundane of applications, there is some joy to be found somewhere.  Don’t keep it all for yourself!  Share those tasks with enough guidance on patterns and architecture to give your team something to get excited about.  They’ll get that accomplished feeling from implementing something outside their comfort zone, which can become addictive.
  6. Lead by Example – Just be your passionate self.  It’s often said that passion and excitement are infectious, so be sure to let it all out.  Sometimes people get stuck in a rut, but you can help make things fun again.

Conclusion

Not everyone is passionate about developing software and that’s alright.  Given the choice, however, I’ll always look for the passionate, or at a minimum, the curious.  Quite often the only thing standing in the way of someone’s passion for development is an experience, some information or some guidance.  If you’re passionate, you can spread the love and infect others.  Be a mentor and give your team something to get excited about.

Posted in Consulting, Developer Life | Comments Off on Passion in Software Development

What kind of developer are you?

Posted by coreycoogan on June 10, 2009


I’m sharing this because I thought it was interesting, especially in regard to team dynamics.  The idea is Productivity Personas, which I found on J.D. Meier’s blog.  It’s definitely worth a read.

Of the different personas, I would say I fall into these, not necessarily at the same time:

– Starter
– Thinker
– Doer
– Can Do
– Simplifier
– Tinkerer

Have a read and see what you are.

Posted in Developer Life | Comments Off on What kind of developer are you?