Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync.
My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded.
The really unfortunate implication here is that learning new technologies is either something that shouldn't happen or something that shouldn't happen on the job. I'd say that something with these requirements would have been a perfect opportunity for Diane to, "learn postgres," if she felt that it would have been better. The extra day or two of effort would likely pay off – if not on this project, then on the next.
> but she also knew that anything much more complex would be beyond her current skills.
And with this mindset, her skills for the foreseeable future.
> Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync.
None of those are maintenance problems, they weren't part of the additional spec. For custom to-spec development, if the requirements change then it's expected that the code will have to change as well, incurring a change order.
A maintenance problem would be something like MySQL being an unreliable DB or the code she wrote being unreadable. If someone needs to go in and fix inevitable bugs then there will be issues.
If the customer wants to add features later then they'll have to pay for the changes and if the new features are different enough from the original spec then the changes might be quite expensive.
The ideal solution would be somewhere between a massively scalable system and a system that just barely meets expected capacity. When an engineer is designing a bridge they over-build just enough that the bridge is solid even when packed with 18 wheelers in a snow storm. Most of the time the bridge won't be anywhere near that load. A great developer builds to the expected capacity + some additional capacity based on the uncertainty of the prediction of capacity. I don't see either Jack or Dianne as perfect developers.
I agree that the "bridge" should be built to the expected capacity + additional due to uncertainty, but that's a slippery slope and one that this article is trying to address. It's a judgement call on what amount of work is appropriate for what amount of capacity, as adding on more capacity due to uncertainty might delay the product or solution from launching.
It may be more appropriate to properly separate concerns and build a flexible architecture that can be upgraded over time to meet needs as they come, or left as-is if those needs never manifest.
MySQL can easily scale to well beyond the "500 users" unless each of those users puts an especially heavy burden on the data store. The scenario at hand is synchronizing recipes and that is not a heavy burden.
Further, with a high-performance web framework, foregoing resilience (not recommended, but just for argument's sake) a single web-application instance should be able to handle a much larger number of users as well.
But all of this isn't really relevant to the point made by the OP. He's just using these fictional data points as an illustration. Although I am personally in favor of using examples that are more representative of reality, I think we can mostly ignore the fictional data points to appreciate his point.
I guess it depends on how efficient you want to be regarding your hardware costs. I have had to replace systems built in exactly this way because of traffic from fewer users than you'd think.
There's a difference between technology and implementation though. If Dianne had chosen a solution that fundamentally can't scale easily then that is a poor decision, whereas a technology that can scale written in a way that can be upgraded later is much more flexible.
As for the MySQL v Postgre I see that as a sensible Agile decision - much more confidence in quality now, with the knowledge that in the future a move to a different DB is beneficial.
The REST/Sinatra/MySQL solution was chosen in contrast to protocol buffers and Cassandra - the scaling potential of the systems are very different.
If you haven't worked on a project of this nature then the complications are likely not to be obvious to you. For instance, once this ships, they will be required to maintain that version of the REST API that was designed forever, including any side effects or semantic weirdness. If they determine that some changes are required for the sake of scale, they need to cross their fingers pretty hard that they can squeeze all of those changes into the existing API.
If this system were truly designed with Dianne's current abilities in mind, we don't know what that REST API looks like. Is it possible to imagine that it sends the full listing of recipes on every request? Absolutely. Are you going to be required to do that forever once the device ships? Yes.
The ideal way is to build for either postgres or mysql, using vanilla SQL, therefore both shipping something that is known to work (mysql, in her case) and learning something about postgres. My observation is aside from anecdotes and peculiar corner cases which should be very strongly avoided, the philosophy of mysql is always the cub scout motto "try your best". The philosophy of postgres is more like "It shall be perfection at all times or I will curl up and die horribly as the ultimate prima donna". When times are good and there's nothing unusual, there is absolutely no practical difference. Its a meaningless personality test to walk up to a dev and ask which outlook on life matches their own outlook and which makes them feel like vomiting. It tells you something about the dev and nothing about the problem. Rarely, if ever, does actual business need enter into the debate.
Postgres/mysql is a business needs decision that needs to be made at a higher pay grade than hers, most likely. Assuming anyone at a higher paygrade knows anything about databases or specifically mysql vs postgres. If no one at a higher level understands, its her job to put it into simple little one syllable words even an overpaid MBA can understand, or they simply have to trust an underling to make a higher level decision.
Something not discussed in the article specifically is this behavior comparison is classic bodger/tinkerer behavior aka Jack vs true engineer behavior aka Dianne. Most people are flexible between the two, some are notoriously inflexible... I have a backyard garden swing built to hold 4500 pounds because that reflected my junk pile at the time and desire to never maintain the swing after installation, although over-specification behavior like that at work would lead to my firing or the financial failure of the company, so I gotta know when to switch. This should have been explicitly discussed in the article.
> I'd say that something with these requirements would have been a perfect opportunity for Diane to, "learn postgres," if she felt that it would have been better. The extra day or two of effort would likely pay off – if not on this project, then on the next.
Perhaps on a product team but for an agency dealing with clients your time is your money. You spend an extra day or two on the project and the client is getting charged for that. Now they're wondering why we're thousands over their budget when the initial perception was we could work within it.
I'm all for learning new things on the job but that opportunity is only for certain situations.
I agree with the op but have a different spin on it. It depends on what you see as your core business. Is your business about the technologies used to build the application or are you using technology to let, "kitchen devices synchronize their list of recipes". If your business is the later then you are better of using tried and tested technologies your developers are familiar with and can maintain without detracting from the core business.
I think the exact opposite holds true. If you're a MySQL / Sinatra shop, being the best at MySQL is the goal - double this if you're working for clients.
If your job is to provide the best possible kitchen device sync platform, then doing on the job research into improving that is essential to the business.
I do not disagree with you. It is all relative and the most important thing is to know what your core business is. Using a car analogy, car salesmen and engineers both need to have technical knowledge of the cars they work with. One focuses on selling cars and the other making the cars. I think too often start-ups are not too clear on their core business. Engineers know the cars better than the salesmen but does that make engineers better equipped to sell cars?
My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded.
The really unfortunate implication here is that learning new technologies is either something that shouldn't happen or something that shouldn't happen on the job. I'd say that something with these requirements would have been a perfect opportunity for Diane to, "learn postgres," if she felt that it would have been better. The extra day or two of effort would likely pay off – if not on this project, then on the next.
> but she also knew that anything much more complex would be beyond her current skills.
And with this mindset, her skills for the foreseeable future.