A good beginning and then it gets worse, i.e. MVP

Why prob­lems occur​” only later”, at the begin­ning it was good and the cus­tom­er was satisfied

Para­dox­ic­ally, the explan­a­tion is quite simple: developers are still dom­in­ated by meth­ods based on mono­lith­ic archi­tec­tures. Preach­ing applic­a­tion” Object-ori­ented pro­gram­ming meth­ods” only means that the so-called​” object-ori­ented pro­gram­ming lan­guage”, which abso­lutely does not mean that the archi­tec­ture of what will be cre­ated will be mod­ern. Audit prac­tice shows that it will rather be an archi­tec­tur­al museum based on a rela­tion­al data mod­el, multi-level inher­it­ance and the worst data mod­el­ing prac­tices, which are an anem­ic domain mod­el and shal­low flat classes with a huge num­ber of oper­a­tions (includ­ing set/get for each attrib­ute of classes rep­res­ent­ing data­base tables).

There­fore, this scen­ario often looks like this: at the begin­ning, soft­ware is cre­ated that per­forms one spe­cif­ic func­tion, often the embryo of a mono­lith. Everything works fine, the cus­tom­er is happy and con­cludes (extends) the con­tract. The next func­tion­al­it­ies are the begin­ning of the drama: expan­sion of the mono­lith­ic data mod­el, migra­tions from the old mod­el to the new one, grow­ing prob­lems of the mono­lith­ic archi­tec­ture: everything is fall­ing apart because everything depends on everything, and no one knows how, because there is no doc­u­ment­a­tion of the applic­a­tion’s oper­a­tion mech­an­ism, and the code has long been no longer suit­able for read­ing. Try­ing to fix this is start­ing to be a bit of a rab­bit chase too…. and there is a dispute.

Source: A good begin­ning and then it gets worse, i.e. MVP – IT-Con­sult­ing Jarosław Żeliński