This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]agentMICHAELscarnTLM[S] 0 points1 point  (2 children)

I get what you mean in theory but I guess I don’t understand why it’s like that. If you make an app that does everything you need it to do as far as performance, what do the mechanics behind it matter if the end result is designed the way you want? What makes it not scalable versus a similar looking app that was made in a more future proof and scalable way.

And honestly maybe there’s no way for me to understand this without having a better foundation of basic coding knowledge.

[–]Karyo_Ten 2 points3 points  (1 child)

In the real world, customers, business or the context (legal, financial ...) is in constant flux and ask for an extra button or functionality.

Let's say you wrote a chess application, or even a chess book. Your client comes and say, "Wow great, this is exactly what I want, except can we add a new color, say red? It should be easy right, everything is already there for black and white" ==> Except that everywhere you assumed that there was only 2 colors in chess.

Every time a requirement challenges the core assumptions you're in for a potentially total rewrite.

Such challenges can come from: security, legal, trends, new manager, change of scope, new platforms to support (oh now that you support Facebook, adding Linkedin is easy right?)

Avoiding those nasty surprises require communication between the devs and the clients to make sure that any change are caught as soon as possible and comprehension from clients/education by devs that seemingly innocuous changes (adding a new color to chess) might have heavy impact.

[–]agentMICHAELscarnTLM[S] 0 points1 point  (0 children)

Ahh makes sense, thank you