I'm in RFP phase working with outsourcing vendors on the 100% rewrite of a fully operational prototype asp.net app that I wrote, to make it commercially viable.

I have an idea for a project design and I'd like some feedback on whether it makes sense. In summary it is to write the JS and the server software in parallel.

Background (which may help in understanding and responding to the question): too many years of IT, kept my "skilled amateur" programming skills, lots of informal project management, lots of work with highly technical people, can drill down to the bare metal, but no "modern" software development team leadership. I have a detailed requirements document, a tasty partial UI/UX design, and the prototype software which again does everything the rewrite should do.

The application is a multi-tenant SaaS subscription-based app. The overall functionality is like a highly structured group forum. The app is not a formal "single page" app, however, the heart of the application is in fact a single page, called the Main Page (very creative). The Main Page in the prototype takes about 20K lines of VB.Net and 10K lines of Javascript (a little JQ, otherwise just raw JS). The target environment will be ASP.NET MVC EF, JQ-heavy client, C# server, AJAX all the way.

An earlier proposal called for two programmers, 3.5 to 4.5 months, plus a .5 Project Manager.

My plan is to hire a short architecture/design phase, and then lead a three person coding team to do the development, with lots of communication bandwidth.

My goal with the new approach (below) is to do the whole project in 2.5 to 3 months by having three coders instead of two, and keep the cost down by getting it done faster and doing the PM work myself.

The challenge I see (and experienced when I wrote the prototype) is that while the Main Page has dozens of transactions and formats that need to be processed, they boil down to a very small set of JSON formats that have to be sent to/from the server. To get started, I had to write a complete (simple) client / server data cycle, and then add to it, one transaction at a time, going back and forth between writing the client code, then the server code, for each transaction.

The NEW design idea is this:
- In general, plan to move a lot of server code (e.g. prepping and filtering client displays) onto the client
- Then, clearly define the JSON data sets that will cycle between client and server
- Build and write two applications
- A temporary "JS Development" application
  - Throw-away CRUD to load JSON tables that are consumed by the client, as if from the server (maybe 10 fields per table, max)
  - An minimal server function to send those JSONs to the client in response to AJAX requests
  - Write all the JS for the Main Page using this application
- A "C# Server Development" application (which would become the "full" app)
  - Throw-away CRUD to load JSON tables that are consumed by the server, as if from the client
  - An minimal client function to initiate consumption of those JSONs by the server
  - Write the Main Page C# business (controller) and data (model) layers using this application
- Put the two temporary applications together when largely complete.

During the main coding phase, one developer would write the client code, another would write the server code, and a third would work on non-Main Page functions in the "Server" application.

I'm hoping to get some feedback on whether this approach is A) crazy, risky, very difficult to pull off, never been done before, or B) ho-hum, used all the time, what's the big deal.

And, if the approach is feasible at all, what would be some risks and critical success factors to look out for.

  • Are you trying to preserve the work of the prototype? Is that why there's so many steps in your plan? I'm not sure that's useful in such a short time frame, other than re-using the protocols and interfaces you've developed. – Robert Harvey May 7 '16 at 19:51
  • This seems like a good set up to having something that seems like it's almost done then finding out nothing quite works correctly upon integration leading to cascading changes to "fix" things. If you're unlucky, you end up with a completely unusable system. A more agile approach is to take vertical (cross-layer) slices (or, put another way, to be feature-oriented) that way you know you'll have something. It's very easy to miss concerns like intermittent failures and concurrent changes that may need significant engineering to deal with with the approach you're suggesting. – Derek Elkins left SE May 7 '16 at 20:36
  • @RobertHarvey: the prototype has some algorithms, some control tables and some elements of the workflow that will come across; otherwise the code can't be considered commercial quality and needs to be discarded. I'm mostly looking to speed things up by working in parallel, in order to reduce overhead and run rate costs. I appreciate the comment on the short time frame. I'm thinking that the shorter time is possible from the fact that the target result is very well defined. – wayfarer May 7 '16 at 21:28
  • @DerekElkins: I appreciate the caution. I just spoke to an experienced programmer who said that separating client and server development ("separation of concerns") is fairly typical practice. That said, I'll do a review of the prototype module architecture (which handles failures and concurrent entries) and look for the type of things that you've indicated, and certainly pay close attention if I take that build approach. – wayfarer May 7 '16 at 21:56
  • How well defined is the interface between the client-side and server-side? – Jay Elston May 16 '16 at 5:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.