How to sell DRY architecture

Question

I'm sure most are familiar with the phrase DRY in the software world - Don't Repeat Yourself. This is a fundamental principle of good software development.

Here is a question (background first).

We are an high level educational institution (college), and are putting together a new MVC application. The current version of this application is for faculty and staff who can perform various tasks such as searching for students, viewing grades and other academic information about that student. There are features to help advisers to enter notes about their students. Likewise, there are views to show overall college details and status for given graduation classes. All of this has security built in maintaining FERPA compliance.

The next thing we are going to do is to implement a "student" version - something the students can log into to see much of the same information - only tailored for the student. They would not be able to see other's information, but only their own. But, they will be able to see the same college level detail information.

My proposal is to make this all one application and use permissions to manage the views and data that is being displayed to the user. Others on the team think that it should be two completely separate applications because of the complexity of modifying the views based on the authorization level of the user.

Some of the problems I am seeing with making this a separate application are:

1. MANY of the views would actually be the same data being displayed. Both the HTML and model code would have to be copied between the solutions - not to mention the unit tests. I don't want to maintain the same code in both places which will eventually become very difficult to maintain.
2. The skins for both sites are the same - any changes would have to be done in both places.
3. The authentication and authorization parts are exactly the same for both applications. We are authenticating against AD and have a common authorization database.

The main reason some others on the team want separate applications is because there is more complexity regarding having to decide who is making the calls and then making sure they get the views and data they are supposed to.

Now for the questions - Is there anyone who thinks I am wrong in my position on this? If so, please explain why so I may understand that side of the equation better. Likewise, if you agree with me, do you have a better way of explaining the given rational with better/more reasons than I've stated above?

Thanks for any suggestions/thoughts!

Answer 1

The biggest reason against two applications is that you are very likely to have to implement user rights anyway. Presumably you aren't going to allow an advisor to enter notes about students he doesn't advise, or delete important information without uber-admin privilege, or edit information about advisors other than themselves? Once you have this mechanism in place, extending it to the students should be straightforward.

NB: If your superiors imagine that academic advisors are somehow above mere mortals in terms of not misusing privileges, they have a wake-up call coming.

Answer 2

Others on the team think that it should be two completely separate applications because of the complexity of modifying the views based on the authorization level of the user.

Really? they don't realise they have to create these views anyway if they made 2 separate applications? How hard is it to put both views into the same application and decide which to show based on a flag!

Now, admittedly that doesn't completely implement DRY but its a very good start - you get to reuse all of the back end code. This is where the majority of the work is going to be done and so this is where the majority of your effort is going to go. UI is almost an afterthought in comparison.

This should get you past the "2 applications" problem, and once they start creating the same view twice in the same project, then I think they'll start to consider the duplication and will start to think of the parts that can be combined in a single view... and then you can say "I told you so" with conviction and smugness :-)

Incidentally, the best applications are writing in a decoupled manner like this, the back-end provides an API that the client consumes. This should solve the 'complexity of calls' problem, as you will design the back-end to provide the required data and logic (hopefully) before you start coding. Imagine you're using data provided by a 3rd party service on the internet - you do not get to tell them what data to provide, instead you call their APIs and use what they give you.

Answer 3

Clearly those for 2-apps solution may lack experience. Just imagine 'adding this one more field' made twice.

Most MVC frameworks allow you to create separate routings for separate users (think of example.com/admin, example.com/student, example.com/professor).

This of course makes a separate views, but (important!) you can extract common parts (RoR calls them partials, cakePHP calls them elements). This is well estabilished approach

(you don't want to end up with if's in your views to determine if you should show this part or not).

Remember this will increase complexity - but not that much. In perspective there are years of managing this app. You'll pay more when maintaining two versions of almost the same apps.

// Edit: Also check julia-hayward response: https://softwareengineering.stackexchange.com/users/43098/ this is excellent point - I would vote it up, but don't have enough points to do so.

Answer 4

The real issue in this case is long-term maintainability of two separate codebases vs. a single codebase. Convincing people who do not understand the problem requires persuasion. Does your school have a computer science department? How about a business school or management department? Some internal support from an instructor would be good.

In short, the issue is this: write two applications, you end up with two codebases, which means potentially twice as much effort to maintain as long as these applications are in use. Sharing modules between codebases can ameliorate this problem to some extent, but if you are going that far with re-factoring your existing application, just re-factor/re-architect it into a single application.

Managers will push back against what they will see as extra effort for no functional gain, and you need to convince them that the payoff comes over the long term. It is also incumbent on the technical team to do a good enough job on the application to validate the argument you are making, so if you decide to push for the solution you want, make sure the team can back it up.

There might be merit to the argument that it will be complicated to change the existing application to accommodate different permission sets, but the complexity being discussed is a problem that should have been dealt with before the first application was built. If the requirement for providing the functionality to students was known ahead of time, it was a mistake not to architect for it. Do not let a past mistake keep the team from making the right decision for the next stage of the project.

Answer 5

I think I have another take on it.

• The faculty and staff application is working and is in use.
• Changing it to create a student application has a large risk.
• I expect that there are few automated system tests for the faculty and staff application.
• They will likely run on different servers, so that the student application does not slow down the staff application.
• They may have different release and test cycles.
• Sooner or later the layout and UI will need to be different between the two applications.

It is possible to share code between applications without having to put it all in one application.

(Some version control systems allow each application to have different versions of the shared code while enabling you to remain sane.)

However I would start by putting the shared code in a common lib, and creating sub classes for each app as needed. A dependency injection system will be to be used, so an application can control navigation between views with having to have all views knowing about both applications.

Answer 6

putting together a new MVC application

Some of the problems I am seeing with making this a separate application are:

MANY of the views would actually be the same data being displayed.   

An argument in favo(u)r of a single app.

Both the HTML and model code would have to be copied between the solutions - not to mention the unit tests. I don't want to maintain the same code in both places which will eventually become very difficult to maintain. Won't the model code be identical, which two views and one or two controllers?

The skins for both sites are the same - any changes would have to be done in both places. 

CSS? Or, you could use AngularJs with templating for your views.

The authentication and authorization parts are exactly the same for both applications.  

We are authenticating against AD and have a common authorization database.

Of course, if that code offers a clean API then it can be used whether you have one app or two.

Personally, I like AngulrJs for this as it so easily lets you show/hide parts of a web page based on a single datum in your controller's $scope.

<div ng-hide="isStudent" class="ng-hide">
   staff specific HTML goes here ...
</div>

and, in the controller, just set $scope.isStudent as appropriate.

So, my vote is for a single app and AngularJs

Answer 7

You should be explicit when talking to your team that this is a trade-off between initial time-to-market of a first version of the student site and the total cost of ownership over the lifetime of the system.

I have seen a real system which evolved over a decade built out of PHP where clients have a extranet micro-site where they can upload/download data/reports to a backend system. They started out with no source control and just literally folder copied the last custom micro-site to start the next customer micro-site and made enhancements only to the latest site they were working on.

A decade later they had hundreds of semi-bespoke micro-sites all on different versions of their code. Remarkably the system was (and is still) successful. This is because each micro-site was "good enough" for the client to do their data entry which was stable for years. The fact that each micro-site had per-client changes was even made into a selling point as "bespoke client engagement".

The key point was that they never had to go back and retest any older micro-sites when they changed anything being worked on for the latest new client. The fact that they could give an inconsistent experience across all clients meant they didn't have to maintain any common code (only some common data import/export logic to the backend systems which they eventually managed to generalise as highly configurable backend code with a flat file interface).

I give this example as there is always an exception which demonstrates the general rule; most site really must give a consistent, "latest and greatest" experience to all users and it wouldn't be rational nor acceptable to work in the manner just described.

With your application if you have lots of logic encoded into the page, with no proper tempting engine, no separated business layer and data access layers, and no isolated data model / object model, with no automated backend unit tests and no automated front-end test, then yes, your colleagues are correct, that leaving what is done alone and starting with a copy, that can rapidly evolve, talking to mostly the same database tables, without going back to fix up and test the existing site, would get a first working prototype up and running much faster than "doing it properly".

Yet after a quick success your employer is going to want to take advantage of their new application to roll-out new features and capabilities which improve the engagement between staff and students. They will expect it to be "one thing" and consistent and seemless not "two things" working hard to stay in sync.

What you need to elaborate is what is the potential long term gain when "doing it properly"; what new common features are the future of the site which justify a shared data model, shared common business logic, templates per user type / user conditional views over the model / logic. If such future requirements exist (which they surely must) then it would be clear that upgrading to an off-the-shelf security/cms framework/engine, putting in a standard conditional templating engine to render the views, designing/enhancing a shared data model, designing common business logic for all users, would get the full end-state experience without twice the code and surely twice the effort and bugs.

I would recommend that you have organise a review of the potential future requirements and suggest going some proof-of-concept work (a few weeks) on coming up with the best approach to best prepare the system to meet those future requirements whilst building out the next phase of the project (i.e. upgrade frameworks/migrate functionality into an opensource cms you can write custom modules to create all bespoke functionality leveraging its framework maturity and user model). I suspect that at the moment people will be focusing on the "upcoming deadline to get the student site live" and thinking about "not doing lots of rework or having to learn something new". So you need to get the customer / boss excited about the target future functionality / end-state and get your team mates excited about "doing it properly" with new exciting new tools and techniques. Then doing the right thing will hopefully become everyones idea. Good luck.