How is Dianne solution not maintainable or scalable? I have used flask gevent and mysql to take similar load. MySQL is not bad at all if you check everything you send it with explain detailed while developing.
The Number One Trait of a Great Developer
41–50 of 122 posts
Re: The Number One Trait of a Great Developer
#42This is a problem because writing working, maintainable code that solves the given problem rather than an imagined problem should be the trait of a competent developer. I had the pleasure of going on a course run by a German developer recently, and his brutal focus on quality and maintainability made me rethink what we class as a good developer. Brutally in the article Jack is not a rockstar - Jack is incompetent. A…
Maybe we should be asking why the things we make need to be maintainable. Why can't I just make program module x to input a and output b and never touch it again. I believe modular code is the future and the sooner we get there the better.
Because at some point f(a)->b will need to be very slightly different, and it won't make sense to write f(b)->b' for performance reasons.
Re: The Number One Trait of a Great Developer
#43Dianne'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 n…
Actually, why wouldn't a web service with a mysql server not scale for many orders of magnitude more users than they expect?
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.
Re: The Number One Trait of a Great Developer
#44Dianne'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 n…
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…
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.
Re: The Number One Trait of a Great Developer
#45Dianne'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 n…
Actually, why wouldn't a web service with a mysql server not scale for many orders of magnitude more users than they expect?
Severe case of "startup disease" combined with "old timers disease".
Re: The Number One Trait of a Great Developer
#46Dianne'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 n…
> 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 chan…
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.
Re: The Number One Trait of a Great Developer
#47This is clearly very dated. Everyone knows that Jack should be a ninja, not a rockstar.
Re: The Number One Trait of a Great Developer
#48This is clearly very dated. Everyone knows that Jack should be a ninja, not a rockstar.
Of course, the usage of both words in this context needs to die. "Jack thinks he's a hotshot developer" would have been fine.
Re: The Number One Trait of a Great Developer
#49This is normal. Some people (you call them Rockstars) are interessted in the newest technology and they want to use them to solve problems. No matter how efficient it is or how good somebody can maintain in. But you forgot one thing: the "Rockstars" use technology, that will be normal for the masses 2 or 3 years later. Ruby, for the first time, was used by Rockstars too. It depend on your company and the size, but yo…
"But you forgot one thing: the "Rockstars" use technology, that will be normal for the masses 2 or 3 years later."
Or sometimes they pick the wrong tech, and it dies, and someone else gets to pick up the pieces 3 years later. Predictions are difficult, especially about the future.
Re: The Number One Trait of a Great Developer
#50The catch-22, of course, is that at some point, MySQL was the "new thing" to Diane, so how did she learn it in the first place? The answer of course is that judgement is less about making decisions upon familiarity per se and more about knowing when unfamiliar technology seems to provide good trade offs given what is known about it. For example, PostgreSQL may be unfamiliar, but choosing it is a wildly different type…
Diane most likely chose MySQL because it was the most popular open-source database. Popularity is often reason enough to choose a particular tool, because it means that that tool is more likely to be supported by other good tools.