I'm the only software developer at the company where I work. I was hired straight out of college, and I've been working here for several years. When I started, eveeryone was managing their own data as they saw fit (lots of filing cabinets).

Until recently, I've only been tasked with small standalone projects to help with simple workflows. In the beginning of the year I was asked to make a replacement for their HR software. I used SQL Server, Entity Framework, WPF, along with MVVM and Repository/Unit of work patterns.

It was a huge hit. I was very happy with how it went, and it was a very solid program. As such, my employer asked me to expand this program into a corporate dashboard that tracks all of their various corporate data domains (People, Salary, Vehicles/Assets, Statistics, etc.) I use integrated authentication, and due to the initial HR build, I can map users to people in positions, so I know who is who when they open the program, and I can show each person a customized dashboard given their work functions.

My concern is that I've never worked on such a large project. I'm planning, meeting with end users, developing, documenting, testing and deploying it on my own. I'm part way through the second addition, and I'm seeing that my code is getting disorganized. It's still programmed well, I'm just struggling with the organization of namespaces, classes and the database model.

Are there any good guidelines to follow that will help me keep everything straight? As I have it now, I have folders for Data, Repositories/Unit of Work, Views, View Models, XAML Resources and Miscellaneous Utilities. Should I make parent folders for each data domain? Should I make separate EF models per domain instead of the one I have for the entire database? Are there any standards out there for organizing large programs that span multiple data domains?

I would appreciate any suggestions.


What you are describing is what happens in many cases: in some ways you are a victim of your own success. You have one successful product and are trying to extend it, possibly in ways you initially did not envisage and design for. And maybe the whole thing is getting too big to fit it all in your head.

With the benefit of 20-20 hindsight, you might have redesigned the original (sub)system as part of the larger one. So what to do now?

  • You don't mention whether you are using a source control system. If not then get one now. The main choices are Git, Subversion, and Mercurial. Do it now, so that when you make changes you can see what you changed, and can undo it. I call it a time machine.

  • Is there an overall design? Do you have pictures of it on the wall? If the design is in your head, or you don't have pictures, produce those pictures now. And label them "version x", to make clear to yourself that they can change.

  • Add to every folder a README file that explains what it is for, is meant to be there, and what is not meant to be there. Later, these simple rules will help you decide where things belong.

  • Even though you are using powerful tools and frameworks, it is easy to scatter business logic in view logic and control logic, and vise versa, especially since the product started so small. You probably feel that you can't stop and untangle that now, but stop adding to the mess. At some stage soon, do a review to locate the stuff that is in the wrong place or at the wrong level, and add comments to the code describing what should happen to it when you get the chance.

  • Remember that abstraction is your friend: if you create abstract interfaces for your components, then you can substitute better or different implementations later. As you have now learned, successful systems evolve. The questions you ask are good ones. But the answer to most of them is "it depends". My guiding advice is to use abstraction to help keep things separate, and use that idea to guide the choices you make. Sorry that I cannot be more specific here.

  • Don't wait until you are totally snowed under before getting help. Discuss with the business leaders what they will do as your workload exceeds you capacity. It can be a scary conversation: approach it as a manager (since it seems you manage the IT Development Department), and show that you are thinking of how the business will manage growth.

Congratulations. It's a good problem to have!

Not the answer you're looking for? Browse other questions tagged or ask your own question.