September 18, 2024 at 12:00 am
Comments posted to this topic are about the item When Do We Worry About Scalability?
September 18, 2024 at 10:30 am
To be frank, I don't see NFRs (non-functional requirements) in general given the attention to detail they deserve.
I perceive NFRs as being putting business context & need around what is being asked of us from a technical stand point.
For example, I need this app to
Beyond those typical NFRs it would be useful to knowing more about the company's position, state and planned activities within the market. Having 5% of a mature market is unlikely to be a changing position whereas 5% of an emerging market could see huge growth.
Knowing that a big advertising campaign is going to hit and the likely response is important. Free flights with every hoover sold etc.
All these NFRs and business knowledge gives us the information needed to choose the most appropriate architecture, infrastructure, DB design etc.
To my mind, it is important that the different disciplines within the company work together and get the communication habit. There is no separation between "The Business" and "Tech".
September 18, 2024 at 12:02 pm
Scalability or popularity first? From what I've seen its popularity first, but who's popularity are you looking for? From my point of view, it is an upper-level manager whose popularity you're trying to appease. At least their opinion matters more than the end users, which I think is sad. After all, who has to use it day in and day out? Certainly, the upper-level manager doesn't, but their good opinion must be achieved before the end users. I've witnessed 8 failed applications over 5 years, some of which I'm sorry to say I participated in. The upper-level manager was happy. But none of those 8 apps are in use today because the end users hated them.
Rod
September 18, 2024 at 3:05 pm
To be frank, I don't see NFRs (non-functional requirements) in general given the attention to detail they deserve.
...
Beyond those typical NFRs it would be useful to knowing more about the company's position, state and planned activities within the market. Having 5% of a mature market is unlikely to be a changing position whereas 5% of an emerging market could see huge growth.
...
The thing I'd say is that most of the time people don't know either those tech or business requirements at that level of detail. They're guessing or hoping, rather than knowing. They might plan for those things, but often as we build and grow, we don't really know what to do. If a business is too optimistic, we over engineer (And are slow to deliver). If they are too conservative, then we're overloaded.
Good points, but the reality of the world I've lived in is that we just don't have good information most of the time, or maybe we can't think widely enough about the ways in which customers might hit our system.
For existing business where we might offer some campaign to entice customers, we may have better predictions, but in that case we'd have adjusted from previous plans and engineering.
September 18, 2024 at 3:06 pm
Scalability or popularity first? From what I've seen its popularity first, but who's popularity are you looking for? From my point of view, it is an upper-level manager whose popularity you're trying to appease. At least their opinion matters more than the end users, which I think is sad. After all, who has to use it day in and day out? Certainly, the upper-level manager doesn't, but their good opinion must be achieved before the end users. I've witnessed 8 failed applications over 5 years, some of which I'm sorry to say I participated in. The upper-level manager was happy. But none of those 8 apps are in use today because the end users hated them.
Building for management is a silly decision. Always build for customers, though ultimately you have to do what the check-signer wants.
September 18, 2024 at 7:23 pm
I've into the questions posed here many times. That's why I'm so careful at interviewing my future employers. 😀 😀 😀
To Steve's point, you should eventually get well-practiced enough to know what's going to work well for performance and what won't. In other words, scalability and performance will just auto-magically come from your fingertips into the code. A part of that is from being able to generate huge amounts of test data to prove some general principles when developing code that's different in some way.
And, I agree... sometimes, you need to do the best you can but tell people to open a ticket to work on "when you can" or be assigned to full time when it does become a problem.
The key for management is to be very careful because, as the saying goes, "If you want it real bad, that's usually the way you'll get it".
One of my mantra's is, "Make it work, make it fast, make it pretty... and it ain't done until it's pretty" where "fast" means scalable and with good performance.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2024 at 7:42 am
For much of my career there has been a dividing line between "the business" and tech. I have to admit, in my early career I was only interested in tech. It was almost like being paid for something I would have chosen to do for a hobby. In hindsight I would have got a lot further in my career if I'd put more effort into gaining knowledge of the business.
Yes most people don't know tech/business requirements at that level of detail but perhaps companies need to make more effort in communicating so more people do! I've sat in management meetings where people have expressed frustration that people don't auto-magically know stuff and that surely something is common sense. The people outside of the room simply didn't have access to the information that would have allowed those "common sense" actions.
Obviously some information within a company has to be restricted and too much will simply drown you. However the right information at the right time would present much better outcomes for the business.
September 19, 2024 at 8:11 am
of course there was a #sarcasm LOL reading this post.
- None of my business side (in-house) clients cares about performance and scalability, but all want best ... until shown the bill for that requirement.
- Most of my devs just want to code the application gui and data is just data and they need a medium to store it
- Most of the dba I know want a correct data model that meets the needs of their client, but are restricted by the metadata / data dictionary they have been provided by their dev partners.
- Especially now, scalability and performance are to be challenged by stepping away from a single medium.
Use the correct medium for things that need to be fast and / or are use very frequently and restrict that mediums data content to the minimum of attributes it requires and ship everything else to a less performance bound medium.
e.g. split actual data from application logging to different media
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
September 19, 2024 at 3:21 pm
...
I've sat in management meetings where people have expressed frustration that people don't auto-magically know stuff and that surely something is common sense. The people outside of the room simply didn't have access to the information that would have allowed those "common sense" actions.
...
A reason I caution clients against adopting too many technologies.
September 20, 2024 at 3:21 pm
David.Poole wrote:...
I've sat in management meetings where people have expressed frustration that people don't auto-magically know stuff and that surely something is common sense. The people outside of the room simply didn't have access to the information that would have allowed those "common sense" actions. ...
A reason I caution clients against adopting too many technologies.
A million likes on that reply, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 20, 2024 at 7:57 pm
A million likes on that reply, Steve.
Thanks. I learned this at Redgate, where we had like 5 web frameworks at one point and realized that it took weeks to get people productive, and we had people not wanting to move to new teams. We also had more technical debt as people adopted new tech and old tech languished.
I see this far too often in Enterprise groups where the benefits of moving to something new are there, but there are more downsides than just the things that might not work as well. The increased bar of knowledge needed, the erosion of skills over time, the impedance to quick context switching. Most enterprises start to regret things when they have 5 CI systems and 9 web frameworks, and some stuff in C#, but a bit of F# someone wanted, a little GoLang, and more.
It's silly to change without clear, high benefits. I think it's worth adopting PoSh in your SQL World, but that's a general look. Any group would really need to debate whether they're better off sticking with T-SQL or even VBScript/Bash than changing.
September 21, 2024 at 10:11 am
This was removed by the editor as SPAM
September 21, 2024 at 10:13 am
This was removed by the editor as SPAM
September 21, 2024 at 10:14 am
This was removed by the editor as SPAM
September 21, 2024 at 5:27 pm
Jeff Moden wrote:A million likes on that reply, Steve.
Thanks. I learned this at Redgate, where we had like 5 web frameworks at one point and realized that it took weeks to get people productive, and we had people not wanting to move to new teams. We also had more technical debt as people adopted new tech and old tech languished.
I see this far too often in Enterprise groups where the benefits of moving to something new are there, but there are more downsides than just the things that might not work as well. The increased bar of knowledge needed, the erosion of skills over time, the impedance to quick context switching. Most enterprises start to regret things when they have 5 CI systems and 9 web frameworks, and some stuff in C#, but a bit of F# someone wanted, a little GoLang, and more.
It's silly to change without clear, high benefits. I think it's worth adopting PoSh in your SQL World, but that's a general look. Any group would really need to debate whether they're better off sticking with T-SQL or even VBScript/Bash than changing.
I worked at a company where they asked me to fix a process that involved SQL Server. To make a really long story much shorter...
The reason there was a need for a fix was it was taking about 45 minutes just to get ONE file of 30,000 rows READY for import, never mind doing the actual import, validation, and distribute of data.
The process used SSIS and the language behind it as well as calls to Perl, Active-X (remember that???), some old VB stuff, and a bunch of other things. That was the first "system" that I referred to as a "Tower of Babel". That's also the reason why people hadn't worked on it...
It took me a couple of days to hammer it out but I ended up doing it all in T-SQL and using SSIS only for some minor file stuff.
The SQL replacement for it identified, imported, validated, and distribute the data for 8 files every 2 minutes instead of the 1 incomplete action on 1 file every 45 minutes.
The reason I bring this up is because the client had simply allowed too many technologies to creep in to the company and most of that was because people were using all those different technologies simply because they didn't know how to use SQL to do things.
I blame the people that teach SQL. The first lesson should be a reminder of how other technologies open a file, read through the rows and checking if there's more rows to read, doing some work for each row, producing some output, and then closing the file. Why?
BECAUSE THAT'S WHAT A SELECT BASICALLY DOES!. SELECT IS A VERY SOPHISTICATED "MACRO" FOR ALL THAT!
And, if it were taught that way, people would understand how to write code in SQL Server a whole lot better.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply