I wonder if architecture code becomes stale as quick as the functional layer or the business layer.
@dagatsoin That interviewer might have meant “replaceable” - which is what I hear when people say programmers are “fungible” - which I can understand even though it’s wrong and offensive. Managers and executives are also replaceable. Thing to tell them when say condescending s* like that is, “maybe... but your users are not.”
In the real world of business where I work, I have to maintain legacy systems and code that is decades old... yes DECADES
Good code, if written well, will pay itself back in multitudes of money because it WILL last a long time
But really, that's not the whole picture. Its not just the code. Its the solution. You can write the best, most maintainable, most correct, code ever... and the solution to the problem was wrong, the code is trashed
One of my colleagues who has worked around many big companies who built expensive ERPs told me how he has seen CEOs spend millions of dollars because they go "oh our ERP is trash. Let's write a new one" And then they sit down to solve the problems... and they come up with the SAME solutions
then someone comes in and writes all new code.. and the whole thing is just as broke as it was before
I have written code from scratch that I then later had to refactor because of massive changes in the solution... and I was able to refactor quickly because I built things right to begin with and it was maintainable. I didn't have to rewrite everything. I have also worked on some horrible legacy systems... and then reality is, it is NOT financially viable to rewrite them, because there are other problems to fix. SO I end up working around the legacy stuff. That is the life of most experienced devs.
If anybody wants to have a solid bottom line, they need code that will last
And then need proper solutions.
HA! Instead the systems get used for decades, because the system works. Except eventually the shortcomings finally catch up.
Moral of the story, good code WILL last.. and it will last a lot longer than bad code
bad code is just going to make you burn threw your wallet and have to rewrite everything much much sooner
People should be expecting code to last. Not the other way around.
If I met someone who said they think code doesn't need to last, I would believe that person is using an excuse to write garbage and rip off the people paying them
I want to point out.... as proof here that Facebook (the people who make react native and keep trying to throw their weight around and lead the world in how they think we should write code) has an entire history built on problems with maintainable code and longevity. Need I point out their first big push in the world? HipHop ? Because they had all these rubbish PHP developers writing slow-performing rubbish PHP, they thought "Hey we have to find a way to make this work. So lets just come up with a new VM for PHP." Obviously, they couldn't afford to rewrite all hteir platform or fire the rubbish developers who refused to learn better languages. So they were stuck maintaining legacy crap
But for some reason, they have instead brought us to this future where the solution is not to build solid well-designed systems. Instead, they have become obsessed over making frameworks so easy your grandma can write some garbage app in it. Except it exudes nasty, architecture you just throw in the garbage when you can't get it to work anymore.
You can't build a long lasting cost-effective solution on that
So I guess if anyone who thinks code is disposable would fit right in at Facebook
I have a potential prospect client right now who has a trash app they have spent a ton of money on... and they want me to go in and figure it out becuase they can't afford to rebuild... but honestly, i'm looking at it.. and the thing is SO BAD and there are so many people, it seems almost unsalvageable. $$
so many problems* not people.. mistyped word
i came here, by the way, because I read the article https://www.infoq.com/articles/no-more-mvc-frameworks/
and i found it very interesting because he talks about all these various web frameworks.. react, angular, etc. I've never in my life used any of them
not a single one
In fact, they look so cumbersome and over engineered to me, everytime i look at trying to learn one i go "there is no way this is going to be fun to use. I'm not doing UI development" and then I figure out how to do work that doesn't involve UI
so when i read the article and the guy shows how you can do fantastic stuff with plain old JS, CSS, and HMLT5, i was like OMG VINDICATED
for the first time ever, I feel actually positive about UI development
simple, well architected code on minimal tech stack that is meant to last is worth gold
It depends the type of code, I interviewed with a startup about 10 years ago who was building a reputation app for restaurants. The core of the app was a screen scrapper that was picking up reviews from the usual suspects. They had spent about 100k just for the screen scrapper. It was deeply flawed and was breaking every other day each time yelp was releasing a change to their page, I rewrote it in a week using a different approach that self tuned continuously, hence didn't break and was giving accurate results in all the tests I wrote for them. Yet, they never wanted to let go their 100k investment and asked me to fix it. I gave up. So I'd say sometimes, code must be disposed...
@jhouxzirrus thanks, unfortunately it's not a common thought. Just for fun I wrote this 19 line of code react-like library https://medium.com/@metapgmr/hex-a-no-framework-approach-to-building-modern-web-apps-e43f74190b9c
I am not saying you never need react, but most people don't. There is also the work of Danny Moerkerke on PWA, very impressive https://whatpwacando.today/
@metapgmr_twitter Your example of the poor restaurant app is exactly what I was trying to refer to when I say code is meant to last and that involves the right solution. Code should be built right the first time so that it CAN last. Code that isn't built right will not last.
Taking the starting mentality that code is not supposed to last is just opening up all kinds of lazy designs utterly doomed
Thanks for the link!
@metapgmr_twitter I have been look at the article you sent showing more SAM example. Correct me if I'm wrong, but am I to understand that you are using this pattern for web apps and single-page web apps? It looks like it is especially good for single-page web apps... or web apps where a single page is very dynamic at least. Is this correct?
Also, I've been sharing this with some of my fellows over at the C# Inn where we discuss architecture a lot... and they find it quite fascinating. :)
One of them said it kind of reminds him of the Capability Based Security pattern. (I'm not actually familiar with that pattern)
Would this pattern work just as well in a forms-based desktop app? Such as WinForms or a XAML approach such as WPF/UWP ?
It's actually good for anything that is stateful. It's a state management pattern, it happens that SPAs are a very good use case for it. I am building a headless app for fun right now that has a very complicated state machine (rule based orchestration) and SAM is very helpful there. I actually don't think of any way I could have built that complex state machine. So yes, it would work well in form based desktop app. The concept of a functional view (aka V = f(M)) is separate from SAM and therefore optional. SAM only requires that you make the state representation available to consumers once the model has mutated.
A(nother) state management library for React
So after a lot more investigation into SAM and MVC, I have this question: Let's say in a traditional MVC pattern, a dev writes code in which the Controller receives actions from the view, pushes those actions to the model, and then turns around and sends a new state to the view. It seems like that's almost exactly the same as SAM... except that the controller is called "controller". If you renamed it to "ModelLogic" or "ModelDirector", how is it any different from SAM? It seems like the only way the controller becomes problematic is if you write logic into the controller that couples it to the view, but you don't have to do that. Does the MVC pattern actually instruct people to do that?
@jhouxzirrus -- I'll give a short maybe simple possibly wrong answer -- @metapgmr_twitter can check my understanding...
In SAM, actions propose changes to the model, not to the state. And the model updates itself and sends the update to the state.
In MVC, the model is passive - i.e., the controller updates both the model and the view usually with data from a service or a DAO. (Unless things have changed in MVC.)
@dfkaye_twitter correct, in MVC the controller is an orchestrator, model and view are subject to the controller (as it name stands). In SAM, an action merely passes a proposal. The model can then accept, reject it or partially reject it. SAM is also reactive, in the sense that the action does not wait for any response from the model. Once the model has mutated, the state representation is computed and published/passed on to subscribers. It's really a question of dividing the business logic. There are also some strong underlying temporal semantics that allow things like debouncing actions, time travel, ... In SAM actions have no knowledge of the "current state" (held by the model). Last but not least, SAM is aligned (but not based on) the semantics of finite state machines so it's a lot simpler to reason in terms of control state when you need it.
Also the separations of concerns is different and more fine grained. The actions are in charge of the logic of preparing the data to be presented to the Model but remains agnostic to it, the Model has also the responsibility of acceptance or rejection, and the State handles the temporal logic or reactions as my understanding. This separation is actually very distinct interesting and different from MVC.