Separation of Responsibility
I remember my first Programming and Algorithms class well. My professor made it very clear throughout the class that we needed to learn not just how to program computers, but to program computers such that multiple developers can work together coherently. At the time, the main purpose was so that tasks could be delegated and code could be segmented so that as projects became larger, we weren't constantly stepping on each others toes to get the job done.As I've grown in my knowledge and experience, I find other things important too. When you scale a project, you can't become a bottleneck that prevents others from doing their job. You can't become a bottleneck that prevents your brainchild from achieving success. Like many software development issues, it pays to make decisions at design time that will make your life easier down the road. Here are a few areas of responsibility that need to be segmented and why.
Authentication
Far too often, simple authentication systems are built to get an application off the ground. That's not a bad thing - it certainly is understandable that you don't want to limit your customers to those who have active directory or kerberos based authentication up and running. It's also understandable that you don't want to delve into those libraries right off the bat for a small application. There will come a time when customers demand a more stringent authentication mechanism, and there will come a time when customers demand that you support their particular authentication mechanism.It goes without saying that you will separate the authentication code. It's the logical thing to do. But a better design is to make your authentication calls generic enough so that they can be easily replaced by another authentication mechanism. When you build permission structures, do so in a way that can be supported in the future easily by an external system. You don't have to know kerberos - you do have to make it easy for someone who does know kerberos well to replace your original code.
Data and Display
This is the one that really chaps my hide. You should never imply a particular display structure based on your logic code. You aren't a designer, you are a programmer. It's up to you to provide the available options, the data structures, and the workflow elements. When it comes to displaying you're data, you are always better off handing that responsibility off to a professional.Keep logic away from data as much as possible. Keep data away from display characteristics without question. That way when people ask you to move something from the top of the screen to the bottom you have a clear place to go update your code and there will be zero chance that your code change will affect the logical inner workings of your software.
Input Mechanisms
Whether you get your data from a file, from a database, or from user input should not matter to your application. Abstracting out your data collecting methodologies will make expanding and customizing your application much much easier.Human Responsibilities
Take all the things that you do and start to categorize them. What starts out as a one man project can one day become a 200 man team. It's important to understand what you yourself do so that you can delegate responsibility to others. Think about the things that you aren't doing, or aren't doing well and be prepared to have a discussion about those things at any given time. When the time comes to scale, you'll be prepared to scale your set of responsibilities accordingly.Join The Clear Separation of Responsibility Discussion
