Keep. It. Simple.
-
Comments posted to this topic are about the item Keep. It. Simple.
-
Great article and links, Steve. Thank you.
Fishing has been perfected. There are no new ways to entice fish to take your bait.
https://getpocket.com/explore/item/timeless-fishing-skills
An old-fashioned cedar plug is a simple but deadly lure on tuna. Photo by Nick Cabrera
There are a lot (perhaps millions) of fishermen, like my Grandfather, my Uncle, and my Brother, who have tackle boxes brimming with perhaps hundreds of lures and jigs, etc, etc. And yet, each year, the manufacturers of fishing lures come out with "new", "improved", and sure to "catch more easier" fishing lures.
Are they trying to help fishmen catch more fish?
Nope. Like I said, that art has been perfected long and, so long as fish are present, you can catch them. Instead, they're trying to catch the fishermen...
... just like software vendors do at least once a year.
Of course, people say that you shouldn't resist change and that if you're not learning something new, you're falling behind. I'm convinced those notions have been planted in peoples minds by those selling the software fishing lures.
If you REALLY want to learn something new and, possibly, make a HUGE difference, learn the only thing you haven't been able to learn so far and that's how to REALLY use wicked old tools like SQL and Excel.
Heh... and, yeah... columnar data is still and will always be a really big thing. Most people are to busy looking at new fishing lures to realize that they need some way to get to where the fish are. 😉
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Certainly learning your existing tools well is important. However, I think you should also be learning new skills and judging when they are useful. That means lots of tests.
For some problems, columnar databases far outperform relational ones. The kicker is, can you move the data to the columnar db with reasonable effort and time?
We certainly know that a system can get overloaded, so how do we handle that? There are solutions, but research, test, test again with a larger workload, and then decide what changes to make.
-
Great article, Steve. When I first started in my career, I naïvely thought that the team I was on could write everything, even the things we didn't need. Oh, was I ever naive.
Kindest Regards, Rod Connect with me on LinkedIn.
-
Kelsey Hightower had a few posts on Twitter championing monoliths. Given that he was a Google Distinguished Engineer this seemed out-of-step with prevalent thoughts on cloud architecture. However the more I think about my own experiences and tech discussions I've had with friends and colleagues the more this rings true.
In the early days of NOSQL a friend was challenged as to why he didn't want a scale out DB Solution. His response was to ask why he would want to scale out for a such a trivial amount of data. This was in the days of SQL Server 2005.
The volume of data may have exploded but I seriously question whether the volume of useful data has.
I'd say start simple and treasure that simplicity for as long as possible. If (and it is an if) you need a more diverse technical estate then let it be driven by need rather than fashion, CV Driven Development and Powerpoint architecture. But be prepare to recognise the need if it arises.
My exposure to distributed systems has taught me that the people who manage to create an unmaintainable monolith transfer their abilities to creating an unmaintainable distributed equivalent
-
Good software engineering is good software engineering. Technology isn't a panacea if you don't engineer things well. You can pay $$ and hide problems for a bit, but not forever.
Ultimately, most of us have mid-sized data or less. The solutions that Google needs for google.com, or Uber, or a few others aren't problems we have.
-
I've always applied the K.I.S.S. method to my work. Keep It Super Simple, or the Keep It Simple Stupid, whatever you prefer. 🙂
I've seen many projects done with what ever the latest 'IT' thing is to only be rewritten later to use SQL and/or SSIS and/or SSRS. This is usually do to those people moving on to other companies and no one to truly support it/and it's just not as efficient.
Don't get me wrong I've seen many SSIS packages that are absolutely not simple. But I 've looked at many of these and can see it would have been a lot easier to do in SQL. Instead of all of the splits and lookups and derived columns and VB. It starts to look like spaghetti code, reminds me of how you had to code in Assembler. On a side note I was going through some old work stuff and finally threw away my old Assembler text book from college.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
To me simple doesn't mean a lack of moving parts, it's more that we can grasp/grok/understand it easily. We use known techniques, patterns, proven things. This is also why it can be hard to get a team to change patterns or adopt something new.
Part of changing patterns is proving something new is better and doc'ing it well
- Steve Jones - SSC Editor wrote:
Certainly learning your existing tools well is important. However, I think you should also be learning new skills and judging when they are useful. That means lots of tests.
For some problems, columnar databases far outperform relational ones. The kicker is, can you move the data to the columnar db with reasonable effort and time?
We certainly know that a system can get overloaded, so how do we handle that? There are solutions, but research, test, test again with a larger workload, and then decide what changes to make.
What I've found is that too many people make the mistake of adopting a technology, such as columnar databases, because of the performance they've heard about only to find out that their data isn't a good fit for columnar data. They try multiple different things except for the easiest one... going back to row data.
The same holds true in many other areas. In more cases that people think possible, they're using a lot of new things simply because they never spend the time to learn the old things... which are frequently a whole lot less expensive, easier to operate, and perform better. To that, a lot of people won't spend the time to learn the true capabilities of the new stuff either and so they are stuck with buying new fishing lures more times than they should.
I'm all for new technology... if it's useful and provides a good advantage over and old way of doing something. Adopting the attitude of "we have to do something... even if it's wrong" is not good strategy. They say that some people are "resistant to change"... I'm not resistant to change... I'm just resistant to pain for no gain and especially if it causes a loss of functionality or other setback.
I've seen way too much of that.
As I've gotten older, I've also made the realization that "A man forced against their will, is of the same opinion still" and that it's frequently a complete waste of my time to say something like "I can do that in SQL". And, so I have to, very reluctantly, give those people the "opportunity to fail" (NOT to be mistaken as setting someone up for failure... I'd NEVER do that). Sometimes that ends up with "Holy S41t!!!! Why didn't you say something earlier"? That's when I have to remind them that I did. 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - below86 wrote:
I've always applied the K.I.S.S. method to my work. Keep It Super Simple, or the Keep It Simple Stupid, whatever you prefer. 🙂
There's also YAGNI (You Ain't Going To Need It).
In general people do things with the best intentions. That includes gold plating IT solutions. I have to hold my hand up here and say that I've gold plated a few of the solutions I've designed and built over the years.
Violating YAGNI will lead to more complex solutions so why did I do it? I saw sparse requirements and no real forum to discuss those requirements. The implications of the sparsity of requirements were that were NSRs (Non-Stated Requirements). NSRs are those requirements that the stakeholder just assumes will automagically be delivered. Deciding what was an NSR and what was a genuine omission was an educated guess. The misses lead to unnecessary engineering effort for features that were never used.
There's also what we used to call the mythical phase 2. This is where a problem of some sort is discovered and the PM/Stakeholder says "we will address that in phase 2". Phase 2 never happens so all sorts of coping strategies get created.
If there was a real phase 2 then the stress and 2nd guessing of requirements wouldn't take place leading to simpler and more maintainable solutions.
- Jeff Moden wrote:
...
I'm all for new technology... if it's useful and provides a good advantage over and old way of doing something. Adopting the attitude of "we have to do something... even if it's wrong" is not good strategy. They say that some people are "resistant to change"... I'm not resistant to change... I'm just resistant to pain for no gain and especially if it causes a loss of functionality or other setback.
I've seen way too much of that.
As I've gotten older, I've also made the realization that "A man forced against their will, is of the same opinion still" and that it's frequently a complete waste of my time to say something like "I can do that in SQL". And, so I have to, very reluctantly, give those people the "opportunity to fail" (NOT to be mistaken as setting someone up for failure... I'd NEVER do that). Sometimes that ends up with "Holy S41t!!!! Why didn't you say something earlier"? That's when I have to remind them that I did. 😀
I'm of the "strong opinions, loosely held" view. I want to stick with things until I see something new working better. Meaning not only is it performing/working/saving/etc. better, but that the tradeoffs are low enough to justify a switch.
There is tech that works better, but every change has a downside, so the upside has to be higher. And you have to prove it, not read it worked for someone else.
- David.Poole wrote:
...
There's also what we used to call the mythical phase 2. This is where a problem of some sort is discovered and the PM/Stakeholder says "we will address that in phase 2". Phase 2 never happens so all sorts of coping strategies get created.
If there was a real phase 2 then the stress and 2nd guessing of requirements wouldn't take place leading to simpler and more maintainable solutions.
I think this is one of the hardest things of DevOps re-framing software engineering for most people. You don't want to have phases. Precisely because of the problems above. You just march along, prioritizing and building small changes. For those that help and are good, you build more, which is another small change. For the things that don't make sense, you stop and close them down.
The project is a long march towards getting better, composed of one step after the other, not phases. Of course, you need to start someone, but you start small with a minimally viable app, or a minimally viable change. Which should be something you build small and test large to be sure it scales a bit. I probably should say TEST
- Steve Jones - SSC Editor wrote:David.Poole wrote:
... There's also what we used to call the mythical phase 2. This is where a problem of some sort is discovered and the PM/Stakeholder says "we will address that in phase 2". Phase 2 never happens so all sorts of coping strategies get created.
If there was a real phase 2 then the stress and 2nd guessing of requirements wouldn't take place leading to simpler and more maintainable solutions.
I think this is one of the hardest things of DevOps re-framing software engineering for most people. You don't want to have phases. Precisely because of the problems above. You just march along, prioritizing and building small changes. For those that help and are good, you build more, which is another small change. For the things that don't make sense, you stop and close them down.
The project is a long march towards getting better, composed of one step after the other, not phases. Of course, you need to start someone, but you start small with a minimally viable app, or a minimally viable change. Which should be something you build small and test large to be sure it scales a bit. I probably should say TEST
I don't know if I agree with either of you on this. I've seen a discussion of "phases", as in, "we'll do that in phase 2". And I've not seen those features that are described as something for phase 2, implemented. But that's because they were always brought up by the users very late in the project/process, just before final release.
Kindest Regards, Rod Connect with me on LinkedIn.
-
Part of the thing with DevOps is you are continually deploying code. A "release" might be lighting up a bunch of stuff that was deployed earlier behind feature flags.
One of the things we've learned in software engineering is that there is always more work, and we might need to reprioritize what we planned to do. DevOps just tries to get work out of the system to the customer, while constantly re-prioritizing things. Phase 2 morphs into this is on our list, above x, y, and z, but below i, j, and k. Once we release x, we might change that list to be k, then y, then z, then phase-2-thing, then i, then j.
It's a mindset shift of pushing everything back to a re-triage of work based on feedback from customers.
-
Steve, that makes sense. I think part of my issue is that, although I understand how DevOps is supposed to work, I don't really have any practical experience doing DevOps. Where I work there's a lot of resistance to use DevOps from both management and my coworkers. I don't really know why. And some of this comes from the customers, too. For example, there's a project we've been working on for 3 years. It's getting close to final release, but the users will still come up with major revisions that would require months to years to redesign. Why couldn't those customers have realized that they wanted what they wanted 18 months ago, when we were dealing with those issues? And I've mentioned before how we have a DevOps team, which refuses to allow any developers onto it. The silo walls are very high here and continue to get higher.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply