I don’t really want to make an “End of 2009, beginning of 2010” post. Mostly because we’re almost in February, but also because I’m sure both of my readers could care less. I do, however, want to mention what I’ve been up to (mostly as just a shout out to all the cool events and people). Last year became SUPER busy right at the end, and so far this year, it’s been exciting too.

I have been traveling quite a bit around the Midwest, speaking at user groups and Code Camps. I did HDC last October, then Iowa Code Camp the first week in November. Then I took a short break for Thanksgiving and helped a little with the SharePoint Saturday KC in December, and watched as a great friend left Kansas City for good (miss you Becky). So far, I have started the year off with Jefferson City .Net User Group and Tonight’s Kansas City User Group. I still have Dubuque .NET UG and Wichita .Net UG in March.

WOW! Sounds like I’ve been busy (feels like it too). But I’ve had an absolute blast. The people I’ve meet are fantastic! I got a chance to meet lots of really smart people and talk to them about things they are passionate about. I’ve learned a lot about programming and about presenting.

I am currently working on a couple of projects that I hope will be helpful to everyone. I can’t say too much right now, but I should be announcing the fruits of those labors soon.

Until then, I hope to see you all around the community.

KAIZEN!

I consider myself extremely fortunate. I go to work everyday and do something I LOVE to do and I get paid quite well for it. Everyone should be that lucky. But about once a year I go through what I call, "Code Burn Out". I still enjoy what I do, I just don't come home and work on my own stuff. I don't spend all my time reading about software development and practicing to make myself better. I spend very little time on Twitter, and I don't even get on my computer very much after normal working hours.

Now you may say, "That's good. You should do that all the time. That's a great way to create a work-life balance and not get burnt out in the first place."

The thing is, programming was a hobby of mine long before it became my profession. I've tried other hobbies and haven't found any others that really stimulate me like software development. I just know I will hit a "slump" about once a year. It usually lasts for about 2-3 weeks. The problem is, this year it lasted for a month and a half.

Of course, I did have extra busy year. I got the chance to travel and speak quite a bit (Thanks to all who allowed me to speak at their events) and helping to run my local user group and organizing the first (ever I think) Kansas City Day of Dot Net. Maybe that's why it lasted so much longer this year. But after about 3 weeks I started to try to think of ways to break out of that funk. I finally did it, and wanted to share in case someone else can benefit. There are several things you can do to get those development "juices" flowing again.

Buy A New Piece Of Hardware

I bought a second monitor. I had dual 24" monitors for about 4 months until one of the monitors started flaking out. Of course, the 90-day warranty was expired, so I just started using one monitor at home. Granted it's a BIG monitor, so I wasn't TOO upset by it. But I recen5tly went and got a second monitor to bring back the duals and it has definitely gotten my spirits up.

Build Something Small, But Challenging

Nothing breeds enthusiasm like success. If you find TDD challenging, test-drive out a calculator app, or a simple website. If you find expression trees challenging, try building a small app that pieces together expression trees. Make sure it is something you can build in a weekend or two and make sure you have plenty of help resources.

Find A Beta (or Alpha) Technology And Give It A Go

If you are the type that likes learning without a net, picking up some Beta or Alpha software that you can try out and learn about can really build that 'Espirit De Code'. This approach can have multiple benefits. Not only will you break out of your funk, but you may be able to help others learn about that technology once it goes live. You also get to submit bug reports and help the developers of the software you are using and possibly even shape the direction of that software. How cool is that?

Get By With A Little Help From Your Friends

Finally, you can just talk to your colleagues about things you're mutually interested in. I work with a guy who is passionate about ALM and Lean software development, and I am too. So talking with him about new techniques, ways to implement lean process in life as well as software really gets both of us going. That kind of interaction can not only kindle passion in your OWN development, but others' lives as well.

I, like many developers, was raised on the idea of getting the database complete before writing the code. The database was the foundation of our application, and building a house without a finished foundation is insane. Also, don’t even THINK about changing the foundation once the house-building has begun. If you MUST change the foundation once development has begun, you’d better have a damn good reason.

When I started to learn about agile and lean software development, I learned about emergent design. Build only what you need for the small piece of the application you are currently building. That includes database, domain objects, services, DAL, everything. It felt very weird to be building membership stuff with no idea of how the rest of the database was going to look. Of course, there is an overall IDEA of what the design MIGHT look like, but until you need it, don’t build it.

There are two main reasons I think emergent design results in better designed software:

You Are Only Thinking About The Thing You Are Building Right Now

On the surface, this might seem like a bad thing. Focusing on the piece that you are currently building helps you to focus on the needs of the functionality you are adding and refrain from building “hooks” into a module for functionality that may never be added, or maybe added in a totally different way. Thinking about future modules (or already implemented modules for that matter) can influence the way you design this small piece of the application as well. Focusing on the fact that other modules need to “use” this module is different than thinking that module x needs to use this module. That thought can lead you to build in coupling between the current module and module x.

You Are Forced To Constantly Change The Application

Again, this may seem like a negative, but changing small pieces constantly makes the application easier to change. If I have to constantly change a module here and a module there every time I add new functionality, I am forcing myself to make each module easier to change. It allows me to see where pieces of my design become brittle and hard to change. This refactoring to ease change leads to loosely coupled, highly cohesive systems, which is what we’re are trying to design.

Use The Force, Luke

In the beginning, it may take some faith and some suspension of disbelief, but once you start seeing designs that are loosely coupled, highly cohesive and easier and easier to change, you’ll start to understand what the original XP Masters were talking about. Just stick to your principles, of writing a spec (test) before you build each granular piece, write the simplest thing that will make that spec pass and then refactor to clean up duplicate or complex code.

Got your attention? Good. It really doesn’t.

Developer’s, in general, are always afraid to let other developers see they’re code. They are afraid they won’t measure up. Since 90% (or better) of the world’s developers are male, maybe that insecurity of what’s under the covers carries over into development. Maybe we just DEFINE ourselves too much by our profession and our coding prowess. I am as guilty as anyone. I am always afraid someone will look at code I’ve written and think that I am a fraud. They’ll look at my tests and get the idea that I don’t know what I am doing.

There are two main problems with this approach:

Un-Critiqued Code Doesn’t Get Any Better

If you are truly serious about getting better at coding, the best and surest way is to let other people thrash it. Let others download it, play with it, give you feedback and send you patches. You have to have a thick skin, because some criticism will be blunt and sometimes just plain hurtful. Understand that even underneath the crap-crusted exterior of a complete flame, may be a small golden nugget of information that might change the way you code for the better. Don’t be afraid to wipe the poo away.

They’re Going To Do It You Anyway

Every group has it’s assholes. The development community has quite a few, and they are a flatulent bunch. They will blow wind about every aspect of your approach from the initial architecture to the final execution. Again, take all that in, wipe off the muck and see if there is anything useful. If not, feel free to ignore them, if so, in a year you’ll be seeing that same asshole commenting somewhere else on the blogosphere about someone else’s raggedy approach. Be assured that they are not moving forward as fast as you, if they are only giving advice and never taking it.

Be True To Yourself

So back to my original statement: “It doesn’t matter if you don’t know what you’re doing.” Put your code out in the world as your approach not trying to purport yourself as an expert, and you’ll see that you get a lot of great advice from lots of great people who were once right where you are now. Even if all you do is ask another coder you know or work with to review your code, you’ll reap whirlwinds of benefit.

OK, I’ve been remiss in my duties as a blogger I know. Can you forgive me? Both of you? C’mon! It was only a couple of weeks. I promise to be more diligent in my posts in the future. So… we cool? Ok.

I am really posting to let you both know that I will be speaking at Iowa Code Camp tomorrow. I have two talks. One on BDD, of course, and one on The Opinionated Web Solution. This is a new talk that is about arranging web projects in a solutions.

If you happen to be in the Des Moines area, drop by.

~Lee

I’ve been a little scarce lately as I prepare for HDC (I’m doing a lightening round), finishing up a project for a client (rollout in a week), and help out some with Sharepoint Saturday, Kansas City (December 12th).

Be sure that I will continue my series on building a dev shop and things should get more back to normal after next weekend.

Stay tuned…

Recently, I read some posts about Duct Tape programming from Joel Spolsky, Michael C. Neel, Jak Charlton, “Uncle” Bob Martin and Jeffrey Palermo. I have followed these posts closely. While the intent is good, I think the delivery suffers.

The whole thing started with Spolsky (as it often does) creating a post that (I think) was meant to say, “Hey stop pontificating on sweet new techniques and start shipping software!” Excellent point. Do that. Don’t worry anymore what other developers might think about the code you’ve written, or you developer “Image” and start delivering business value. Spolsky’s Duct Tape Programmer uses Duct Tape and WD-40 to get the job done, and it reminded me of another archetype I’d been exposed to earlier in my life.

The Backyard Mechanic

The Backyard Mechanic, if you’re not familiar with the term, is a term used to describe those guys who have been around cars all their lives. They rebuilt their first Chevy short-block 350 at age ten, and have always smelled like axle grease. I like these guys. With the exception of the rebuild, I am one of these guys (it was my Dad’s Ford 302 and I was 13). If I am ever broke down on the side of the 395 between Barstow and Tahoe, I want this guy riding shotgun. He will get me to the next town. He will make sure I get there. But I would NEVER pay these guys to work on my car, not even myself. Why? Because the “Git-R-Done” tips and tricks they use are simply patches. They know how to compress a brake caliper with a crowbar and a piece of wood, but a brake tool work much better and won’t run the risk of breaking (no pun intended) your knuckles if your hand slips. If I am overheating because of a leak in a radiator hose, I can put duct tape on the hose and piss in the radiator to get me to the next town. But I certainly don’t want to run my car on piss & Duct Tape on a daily basis. I guess my point is, when people PAY you for a job, they expect quality. They also expect you to get their car fixed as soon as possible, and I guess that’s Spolsky’s point.

Ship The F___ing Thing!

In Jak Charlton’s post, he talks about the alignment of business and IT and, to me, that is a more important point. In the “Project Triangle”, (Time, Quality and Functionality) you can only focus on two sides at once. The point is, it is not up to IT to make those decisions; it is up to the business. Developers need to align their development goals with the business goals of their customer. It sounds obvious, but it doesn’t seem to happen as often as it should. If the business decides to focus on functionality and time, the programmers should focus on functionality and time as well. But the business should be making an informed decision when they decide to let quality slip. They should know what it means to let quality slip and THEY SHOULD DECIDE that quality is less important than functionality and schedule. They should be made aware that the second version of this product might require a complete rewrite (let’s hope not), but they should be aware of that and walk into that decision informed and with their eyes wide open.

Quality Saves Time (And Not Just In The Long Run)

This doesn’t mean scrap the idea of quality programming all together. What it means is that, given the choice between time, functionality and quality, time and functionality win and we understand quality may suffer. From what I’ve seen, quality software actually saves developers time. Now, writing fifteen layers of abstraction and creating a new development framework for your project does not constitute quality. That’s architectural masturbation. Following the SOLID OO programming principles at the very least can certainly save you time, and not just in the long run. The fact that quality code is easier to change and enhance, means that as you build feature 2, 3 and 4, it will be easier and easier to do without having to re-factor chunks of existing code to do it. Techniques like Test-Driven or Behavior-Driven Development were developed out of a need to deliver software quickly without letting sacrificing quality. When done correctly, not only does TDD speed things up, it gives you a low-level regression suite that helps you ensure you didn’t break anything WITHOUT having to go manually test everything again (a MAJOR time expenditure). ORMs save a tremendous amount of SQL writing, not because it’s hard to do, but because it’s time consuming, and if you’re looking to ship fast without sacrificing quality, a battle-tested ORM (like NHibernate or SubSonic) can be a great fit. Finally, quality saves time just be cutting re-work. Doing it right the first time, means you shouldn’t have to go back and redo it a second time, which should save you time as well. All this is real time savings in the first version, not some hopeful future-vision of time savings down the road.

Quality Is A Requirement

Ultimately, quality should be a customer requirement. I don’t mean as in it’s required, I mean as in the customer should specify the expectation of quality. When gathering requirements, it might not be a bad idea to ask, “..and how high should the quality be?”

It sounds like a dumb question, and it will need some qualifying when you ask it, but it can help. Telling the customer about the project triangle, if they don’t know about it, and explaining how each side influences the outcome of the project can be invaluable. The way I tend to breach the subject is, “If I am building software for an EKG machine, I probably need to ENSURE the highest quality, even if it takes a while, but when building a corporate website, if the outgoing email from the contact us form says ‘Thanks for your fedback’, no one is going to die.”

If you don’t make the customer specify which side of the triangle is the least important to them and help them understand what letting each one slip means, you’re telling them you’re going to deliver 100% on all three sides, and your project is doomed. For the most part, businesses understand what letting the timeline or the functionality slip means, but as developers we need to make them understand what letting quality slip means to them. Otherwise, they will not understand why it takes you twice as long to make changes to the codebase after version one, if you don’t.

Finally

I guess my biggest point is don’t start by sacrificing quality. Duct Tape and WD-40 are awesome tools and every developer (and mechanic) should keep some in his toolbox. But that shouldn’t be the first tool you grab. When time and functionality are the most important things, I would start by looking to tried-and-tested tools (like an ORM or a scaffolding framework) to help get thing delivered quickly without sacrificing quality. Then once you have exhausted all of those avenues, reach for the Duct Tape to limp the thing home (until you can fix it properly).

That’s all of my rant for now. It is my opinion, I am entitled to it, and dog-gone-it people like me.

Well, here we are again. Last time, we talked about project structure and came up with the one we’ll use for this series. Next we’ll talk tools. We’ll talk tools like Tim Taylor talks tools: with lots of grunts for my favorites and only a little explanation about what the tools do.) This is mostly because there is LOTS of material on the interwebs about all of these tools. I tend to favor the tools that are the most widely used for two main reasons: they have been battle tested by the largest crowd and two, they usually have the largest volume of content written about how to use them; some more useful than others. Having said that, let me also say that my choice of a specific tool doesn’t mean that the others in that space don’t have value. Most of the tools I will mention are all well respected by the well respected and each has its own strengths and weaknesses. If you are in charge of picking a developer stack, do your homework, but you could start with the stack I use and change fairly easily, if the particular tool doesn’t fit your needs. I will also easily swap one tool for another, if it will make the development process easier. ALT.NET… respect.

Getting on with it, there are several practices that I engage in on almost ALL projects that have tools that make them easier to do. The most important thing about a tool is that it should stay out of your way. Once you’ve set the tool in your stack it should grease the wheels of development. If it doesn’t, it’s either not the right tool, or you’re not using it correctly.

ORM or OR/M or O/RM (not sure where the slash goes)

An object-relational mapper is a tool that allow you to map your object model to your relational database (thanks again, Captain Obvious). Basically you tell your ORM that your Person object is stored in your People table and that it’s FirstName property maps to the FirstName field in that table and so on. Linq To SQL is an ORM. There are tons of them out there now. From free stuff (Subsonic, NHibernate and Castle ActiveRecord) to paid ones (LLBLGenPro and Telerik OpenAccess ORM come to mind). One of the things that will help in a transition to an ORM is adopting the idea that the relational database is merely a way to persist your object data. I have used only two and a half in the past: Nhibernate, netTiers and SubSonic. I say two and a half because I have not used SubSonic extensively or on a production project.. yet. It looks very promising. I choose NHibernate because of its many ways to map objects and it’s humongous user base. If I am hiring developers I can actually ask for NHibernate experience and probably see some.

IoC Container

IoC is inversion on control (so the C doesn’t stand for container and make for doubled-up words like GCO Carpet Outlet – Georgia Carpet Outlet Carpet Outlet). An IoC container helps to inject dependencies and works a bit like a factory method on steroids. If I have a dependency on a type, I can inject that dependency by inverting the control over that dependency to someone outside myself. If that made no sense, that’s ok, here’s how it works.

I need a laptop to make my presentation at the conference, but instead of lugging around my laptop (cause she’s a big girl), I can ask the conference to provide me with that laptop and bring only my presentation on a thumb drive. I am inverting the control of that dependency to the conference coordinators, and telling them it must have PowerPoint and Visual Studio 2008 on it. I “depend” on that contract. When I get there, I just ask for my lappy and plug my thumb drive in and away I go. This loosens the coupling to my machine. I don’t HAVE to have MY MACHNE to do the presentation. When I need a laptop for a talk, I just find one with PowerPoint and VS2008 and I get that dependency handed (injected) to me.

There are many free IoC Containers out there as well (StructureMap, NInject, Unity and Castle Windsor just to name a few). I chose StructureMap because of the large number of resources I found when doing research on Inversion of Control and Dependency Injection. (Also, Jeremy Miller is from Missouri, even if he lives in Texas now). I also feel very comfortable with the way you register you dependencies in StructureMap, although that could just be because that’s the tool I used to learn about Dependency Injection with.

BDD and the Infinite Melancholy

When driving a project, I try to drive it from the requirements (again, shaddap Captain Obvious). What I mean is, I try to codify those requirements so that they are executable. This makes them verifiable at every step of the project. Instead of “winging it” and hoping the change I just made doesn’t break something I developed yesterday or last week, I write the “specifications” in executable format, so I can use that as my checklist of what the system can do. I can also all the specs at any time to make sure everything still works as required by the customer.

For BDD, I choose Machine.Specification or MSpec. The syntax is very strange for C# developers at first, but I find the English-y way the code reads to be very compelling, and the report that it generates is a top-notch artifact to pass on to stakeholders. There are also other BDD frameworks out there (NBehave, NSpecify and you can even use RSpec (Ruby) to spec out your .Net code if you are so inclined.) Also, there are a few extensions to traditional unit-testing frameworks out there that allow you to work in a Behavio(u)r-Driven way (SpecUnit.NET, DevelopWithPassion.BDD and recently Gary Shutler has done a series on building your own BDD framework.)

Mock Me? Mock YOU, PAL!

If you’re going to do TDD/BDD, you’re going to need to mock. It’s that simple. If I tried to drive my design with BDD without using mocking or IoC, I would stab myself in the neck with a spork. Mocking is simply a technique of using “fakes” or “stand-ins” to isolate sections of your application in order to drive out their design. Remember, using BDD requires writing your spec first, THEN writing code to make it complete. By that very definition, you’ll be dependent on code that you haven’t developed yet and that you’re NOT going to develop yet. Mocking is the only way to get this done.

Again, there are free mocking solutions out there (Moq, NMock and RhinoMocks) and paid solutions (TypeMock). I’ve never used TypeMock, but I have heard that it can mock just about anything and if you’re trying to do TDD in SharePoint (I’ve heard) it’s the only way. I choose RhinoMocks, again because of the active user base and Oren Eini’s inability to stop coding/blogging/teaching for one second.

Architectural Pattern (MVSomething)

I started using a model-view-presenter pattern a couple of years ago, after I read an article from Jean-Paul Boodhoo in the MSDN Magazine in August of 2006 and a blog post from David Hayden about the Unity IoC container where he used Unity to wire together his Views and their presenters. It was an easy transition for me, because it felt a lot like web forms. At the time, ASP.NET MVC was in early preview releases and we had a significant investment in Telerik controls which (at the time) relied on ViewState to do some of their magic, and ASP.NET MVC doesn’t have ViewState available. I used MVP happily on several projects and still use it when a project requires ViewState or must be written in earlier version of ASP.NET.

ASP.NET MVC is the new kid on the block, but is making a huge impression. On me, as well. I have just begun to really dig into ASP.NET MVC, but the Sharp Architecture project can give some good guidance on how to set up, arrange and even test an MVC app. This is ultimately the one I have chosen for the project in this series, because it is very powerful and something I really want to get more familiar with.

Them Model-View-ViewModel pattern is the newest kid on the block and permeates the WPF stack (WPF Windows and Silverlight Apps). It is especially effective where two-way binding for your View to your View-Model is possible.

Quite a lot has already been written about all of these patterns, and rather than rehash them, I will just give links in the references area.

A-budee—A-budee—A-That’s all folks

I knew this was going to be a long post. We covered a lot of topics very lightly, but I felt it was important to give a short background on why and what we’ll use in this exemplary series. I’ll leave it at this for now, with some links below for more exploration. Then, next time, we’ll actually create the base project and set up it’s continuous build on our TeamCity CI Server!

Link-age

MVP – MVC – MVVM

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

http://davidhayden.com/blog/dave/archive/2008/02/19/ASPNETModelViewPresenterUnityIoCMicrosoftPatternsPractices.aspx

http://weblogs.asp.net/scottgu/archive/tags/MVC/default.aspx

http://haacked.com/Tags/aspnetmvc/default.aspx

http://code.google.com/p/sharp-architecture/

Mocking

http://martinfowler.com/articles/mocksArentStubs.html

http://weblogs.asp.net/rosherove/archive/2007/04/26/choosing-a-mock-object-framework.aspx

http://ayende.com/projects/rhino-mocks.aspx

http://devlicio.us/blogs/tim_barcz/archive/2009/03/19/choosing-a-mocking-framework.aspx

BDD

http://code.google.com/p/nbehave/

http://nspecify.sourceforge.net/

http://github.com/machine/machine.specifications

http://blog.robustsoftware.co.uk/search/label/BDD%20from%20scratch

http://www.lostechies.com/blogs/derickbailey/archive/tags/Behavior+Driven+Development/default.aspx

http://blog.scottbellware.com/

Inversion of Control / Dependency Injection

http://structuremap.sourceforge.net/Default.htm

http://ninject.org/

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

ORM

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

http://nhforge.org/Default.aspx

http://subsonicproject.com/

I might have made a decent lawyer. If I’d been born without any self respect and complete absence of morality, I might’ve become a lawyer. I love to argue. I love it. I like pitting my ideas against another’s. I like that at any moment I might have an epiphany and change my perspective or opinions about something. That’s learning. Basically, in technical arguing, I’ve seen basically three scenarios.

The Salesman

First is the useless scenario. Someone has a bone to pick or an agenda to push. This is the most frustrating scenario. In that case, I am not arguing your perspective against mine, and there is no way you will ever concede defeat, because you have a prize that you are after.

The Amicable Divorce

The Second scenario is that we agree to disagree. To me this isn’t much more useful than the first. I still may learn something and later when researching your points, I may find golden nuggets of information that I can learn from, but generally, this means that one of us couldn’t convince the other, but were just not comfortable conceding the point. If I do this, I generally assume that I am wrong and quickly start researching your points so I can figure out where I am wrong if I am right, I will be better equipped to convince you (or someone) next time.

Teach You, Teach Me

The last scenario is: We argue, one of us concedes the point and we end up learning something. That’s my favorite. I love to learn and I love to teach. Even more than I love to argue. (And I argue with myself in the shower just to keep in practice).

Ultimately, I like learning more than anything else, and arguing is a really good way to learn something. The problem is, you have to argue your point fervently, while keeping your mind open to the possibility that you’re wrong and be ready to stop on a dime and say, “Hey, I think you may be right!” The flip side of that is, being ready for the other person to say that you may be right without being a jerk about it.

Danger, Will Robinson, Danger

First, Be ready to answer all questions, and don’t EVER be afraid to say you don’t know something. Faking your way through an answer or an argument is a surefire way to get someone not to trust your arguments, and possibly lose interest in arguing with you altogether.

It is also important to be aware of your arguing style and warn others, however. I have a very animated arguing style, and I am six-foot-five and 350lbs. Seeing me wave my arms and raise my voice may throw people off, but I am truly harmless, and I am NOT using this style as a tactic to win an argument. (At least not a technical argument.)

So feel free to argue with me, and if you prove me wrong, I learned something and I owe you one.

Alright dear readers (both of you), I told you last time that I would answer that age-old question, “How many projects should I have in my solution?” The answer is: only as many as you need. I know, I know, but it’s not a copout, really it’s not. I’ve really found that is it easier to start with fewer projects and break them out when you need to, than trying to combine projects later on. Does that mean that one project with everything in it is right? Yes. If that is all you need.

I realize it sounds like I am being wishy-washy, but I promise I am not. For the sake of being opinionated (because “as many as you need” is hard-to-follow advice if you are looking for guidance), I will say I normally find that I have three projects. I tend to call them Web.UI, Core and Specifications. For this series we’ll be building a web project, but you could just as easily swap the Web.UI project for a WPF.UI project. Now, if you don’t consider the Specifications project as part of the “According to Hoyle” project, then I only have two projects. 

The thing that I will do is namespace everything within the project n a way that makes it easy to break them into their own project if I need to. So I had my data interfaces in a data folder (with that namespace) and inside that a folder for each type of implementation (e.g. an NHibernate folder, a SubSonic folder and an Entity Framework folder). This sill allow me to make a new project called Core.Data.NHibernate and move those files over and hopefully not break anything (I haven’t needed to do that yet).

I have been using this project structure for a while and am pretty happy with it. It came from stealing little ideas from respected developers around the community, and hashing it out with my co-worker, Troy. He is the one who kept reminding me that I didn’t need all those projects in the solution, and eventually we whittled it down to these three.

One thing that I will also do, is have my Specifications project a folder above the location where the Core and Web.UI projects are in the file system. I stole this Idea from Sharp Architecture and it makes for good, solid separation of the Specifications from the rest of the production code.

I hope this gets you ideas flowing for your own solutions and gives you a jumping-off point for deciding just what your solution needs in it. This should also be a good way to get the (civilized) conversation going about your won project structure within your team.

Next time, we’ll talk about tools. We’ll briefly discuss why you would use each tool and what comparable tools are out there. We’ll look at application architectural patterns (MVC vs MVP vs MVVM vs Web Forms), ORM tools, IOC containers, mocking and testing frameworks and some helper libraries that might make it easier to do some things within your own project.