I work in a manufacturing plant that has tasked IT with creating a shop floor scheduling program (that is very badly needed). Based on others experience, would it be better to take less time and build out a basic framework that is usable and then build upon that by adding features or start out by creating a fully implemented solution right out of the gate. I've only been a developer for about a year and don't have very much experience with initial creation of apps of this size. I've been leaning towards the idea that a barebones app is the way to go first due to the extreme need for some type of digital schedule but am concerned that adding random features after the fact could get a little messy. If you were in the same situation what path would you lean towards?

  • 1
  • 3
    Forget the framework thing in this context. Build an app, not a fancy framework.
    – keuleJ
    Commented Feb 9, 2017 at 6:00
  • 2
    no matter what you do you will ultimately be building it a piece at a time .building said "framework", which hopefully means something other than writing a framework as you go. The question is, do they want you to release asap, and give feedback... this is usually the better route. Also, no offense to you, you should probably suggest they bring on a senior developer to help with an app of this size. Whatever they want they probably think it can be done faster and cheaper than it can be. Commented Feb 9, 2017 at 14:23

4 Answers 4


Experience definitely leads toward building something small and simple, and getting it to the users as early as possible. Add features and capabilities as they're requested by the users.

Chances are very good (bordering on certain) that what they want/ask for won't resemble what you would have built on your own very much (if at all).

As far as things getting messy as you add to your original application: well, this is why Agile (and most similar methodologies) place a strong emphasis on testing and refactoring. Refactoring means cleaning up the code as you make changes, and a solid test suite (that you run every time you make changes) ensures that if/when you introduce bugs you know about them (almost) immediately, so that when you release something to your users you have a reasonable assurance that it actually works.

  • Very good point with the distinction between what they ask for and need and what we think they do. I think the biggest hesitation that I was thinking about was that between the time they tell us what they want and the time we come up with a solution their wants completely change. But I guess small and simple is definitely easier to change then full featured. Commented Feb 8, 2017 at 21:36

Do you have any idea whether they are serious about the app, then you may not want to build frameworks, etc. etc.

However, you need to find a balance. Agile development suggest you focus on what is required by the app at this stage but this does not mean you have to limit yourself by neglecting basic design. There are things that can easily seen as coming (and yes experience plays a role here) and others that you can't imagine at this stage (I am pretty sure the people who asked for the app can't imagine them either).

I don't know the details of the scheduling app but I can imagine that the "type of appointments" is something that you will come across soon. Perhaps people don't ask for this now not it is reasonable to expect such functionality.

I would approach this case as follows: I would build the infrastructure (the framework you mention) by creating a table in the database to hold appointment types but I wouldn't bother to create the interface to add or select the types. I would hard code a basic type and move on with the actual features. After all, no one asked to include different types of appointments.

Then, in the future, if people come back to you asking for this feature, you have the structure and you just build the mid/front end.


Often, you do not have enough information to build an initially complete program. Testing and customer feedback almost always reveal parts of your initial design that were not as good as they were in theory.

That said, if the problem is well understood and you are able to write a complete program initially, this is better because otherwise you are constantly refactoring the code and the result is rarely as clean as a solid design that was followed from the start.

At the very least, I think it's important to think hard about the type of featured your program might need. That way, you can design it so that such features can easily be added within the existing structure.


From personal experience: build your MVP (Minimum Viable Product) and then add features to it based on the feedback you recieve. It is easy to get tonnes of features and not have anyone use them.

Also important is the user experience that you use to solve the problem. Validate the workflow you create with your actual users and then go about adding further features. That ways you can focus on the core value that you are building.

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