Posts
417
Comments
233
Trackbacks
42
Random Thoughts On Software Development

I was listening to an episode of .NET Rocks in which Ted Neward spent some time discussing the direction that languages are going.  This was predominantly a discussion of the DSL concepts, but the interview got me thinking about languages and how we design the internal structure of applications.

One of the main things that struck me was that something about objects has never felt quite natural.  I have never found a decomposition technique that I was satisfied with.  Looking at objects as nouns in your domain was an easy way to start.  The problem was defining where operations lived.  Some naturally belong within an object and others landed in a gray area.  So you start creating objects that are data transfer objects which are operated on by objects that are method containers.  When you do this you find that you are really just doing procedural development in an object environment.

Coincidentally Scott Hanselman had a show on SOLID with Uncle Bob (Robert C. Martin) around the same time as the .NET Rocks show.  Below are the principles that make up SOLID.

  • Single Responsibility Principle
  • Open Closed Principle
  • Liskov Substitution Principle
  • Dependency Inversion Principle
  • Interface Segregation Principle

Note: Uncle Bob noted that he came up with the acronym before someone else suggested calling it SOLID.

These are the type of principles that I both admire and they drive me nuts.  On one hand you have a “duh” moment when you are told to limit the number of reasons that an object should change to one.  On the other hand, the lazy developer inside you says “that is going to take a lot of typing” as you create ever larger numbers of objects.

Ted indicated that we thought that objects were the way god thinks about the world and this was the end-all-be-all.  In reality we find that some parts of software should be simpler or even abstracted further.  This is why we are coming up with more scripting languages as well as DSLs with code generation.  If a concept calls for a lot of detail but is one logical unit that can be reused then abstract it to a higher level.  Don’t right it repeatedly at its lowest level.

One of the best questions brought up was “what do you want from a language”?  This is a great question which of course brings up more questions.  Where do you draw the line between language and design.  Ted commented that languages are designed to reduce complexities so that we can attack greater complexities.  This is another one of those “duh” moments, but if we don’t keep this in mind we will often use the wrong tool for the job at hand.

The key is to use tools and techniques where they make sense.  Dogmatic use of a single technology or design approach is an invitation to disaster.  Fill your tool box with hammers, chisels, screw drivers and anything else you can acquire so that you aren’t using a butter knife to carve a wooden figure.  Learn as many languages and software packages as you can find time to.  Don’t worry like most people do about forgetting what you leaned.  It will come back to you when you go to use it again.

In the end the best tool you can ever have is knowledge and experience.  Evaluate what you have learned after each project and leverage that for the next.  Never stop looking for a better mouse trap, but if a simple spring trap will work use it.

posted on Wednesday, January 21, 2009 9:48 PM Print
Comments
Gravatar
# re: Random Thoughts On Software Development
Ryan
2/20/2011 6:35 PM
Is there a particular reason you chose to use SSRS? I've had a bit of experience with simple SSRS reports and absolutely hated it. We ended up investing a few days in building an MVC based reporting framework that gives us online reports, automated PDFs, CSV formats, and emails and now we can hammer out reports in a matter of minutes to hours (depending on complexity). We can even unit test the logic if necessary.
Gravatar
# re: Random Thoughts On Software Development
Tim
2/21/2011 5:34 AM
Historically I have stayed away from reporting as a whole. I have always ended up fighting the tool instead of working with it.

I this case it was a requirement for the project. It also give the stake holders some ability to do simple reporting themeselves. Adding another reporting framework that wasn't directly under support agreements with Microsoft adds a certain level of discomfort for a number of clients.

Post Comment

Title *
Name *
Email
Comment *  
Verification

Tim Murphy

Tim is a Solutions Architect for PSC Group, LLC. He has been an IT consultant since 1999 specializing in Microsoft technologies. Along with running the Chicago Information Technology Architects Group and speaking on Microsoft and architecture topics he was also contributing author on "The Definitive Guide to the Microsoft Enterprise Library".



I review for the O'Reilly Blogger Review Program



Technorati Profile

www.flickr.com
Tag Cloud