Interview question


  • Discourse touched me in a no-no place

    I ask this question in interviews. It's one of the few of our stock question bank that actually has what we consider a correct answer.

     

    "Please rank the following 3 attributes of a program in order of importance. Most important to least. Just number them. No explanation is needed.

    - Efficiency. As in the resource footprint of the code on the hardware.
    - Supportability. As in how much work it takes to maintain, how buggy it is, and how traceable/auditable the data is.
    - Compactness. As in how elegant the code looks."

     

    I've done more interviews in the past month than I care to count, and I think I've heard the right answer 3 times. And no, I'm not going to tell you guys what the correct answer is (right away, anyway) - because I want to know what you think it is, just in case I'm totally off base.



  • Not developing software as a profession, I would rank them, highest to lowest:

    • Supportability.
    • Compactness.
    • Efficiency.



  • #1 Supportability - By far the most important. No exceptions.

    #2 and #3 depend on the context. If the app can potentially be under a heavy load, efficiency would be more important than compactness. Beautiful code won't make the app responsive. On the other hand, for apps that do not take much punishment, compactness gets #2.



  • Supportability is by far the first priority, as unsupportable software will cost the business massively in the long run. Of the other two, it's close, but I'd say efficiency comes second and compactness third, as inefficient code can waste hardware, also costing the business. You could say that compactness is more important because hard to understand code wastes manpower, which is more expensive than hardware, but I'd say that defining it that way really subsumes compactness into supportability - also, elegant code, while compact, is not necessarily easier to understand, and in fact can be harder to understand for someone who doesn't know the ins and outs of the language in minute detail, making compactness almost an antigoal.


  • Discourse touched me in a no-no place

    @ekolis said:

    Supportability is by far the first priority, as unsupportable software will cost the business massively in the long run. Of the other two, it's close, but I'd say efficiency comes second and compactness third, as inefficient code can waste hardware, also costing the business. You could say that compactness is more important because hard to understand code wastes manpower, which is more expensive than hardware, but I'd say that defining it that way really subsumes compactness into supportability - also, elegant code, while compact, is not necessarily easier to understand, and in fact can be harder to understand for someone who doesn't know the ins and outs of the language in minute detail, making compactness almost an antigoal.
    This is exactly what we're looking for. Most often, this order is completely inverted. And the ones that invert it are also always the ones that completely miss the "No explanations. Just number them" part and blab on and on about why they're right.



  • I'd actually question all three of your definitions, and possibly even give different answers depending on whether we were using the words, or the definitions you have given the words.

    @Weng said:

    Efficiency. As in the resource footprint of the code on the hardware.

    This is only one type of efficiency - and its importance depends very much on context. In embedded systems, I imagine it would be critically important. In an ordinary server environment, less so. I imagine you could write a bogosort wth a tiny resource footprint - but is it efficient at achieving the desired outcome? Definitely not. Program code that required more resources but processed the [i]data[/i] more efficiently would be more important in many situations.

    Supportability. As in how much work it takes to maintain, how buggy it is, and how traceable/auditable the data is.

    Conflating correctness, maintainability, and traceability. Auditability is vital in some contexts, but drops to desirable in others. Code that is easy to maintain may still be buggy, and code that is provably correct can be difficult to maintain.

    Compactness. As in how elegant the code looks.

    Conflating compactness with elegance. There are cryptography algorithms compact enough to be tattooed onto someone's arm, but I wouldn't call them elegant if I had to maintain them. If you mean elegance, say elegance.

     



  • None of those are what I'd consider most important, but of the three: Supportability, followed by Compactness, followed by Efficiency as a distant, distant last place.



  • @ekolis said:

    also, elegant code, while compact, is not necessarily easier to understand, and in fact can be harder to understand for someone who doesn't know the ins and outs of the language in minute detail, making compactness almost an antigoal.

    Agreed. The desirability of compactness tends to depend on your definition of what is compact code. There are truly beautiful little snippets of code (especially in the demo scene) that, with a dozen characters, can do the most complex and beautiful things. Those are generally the ones that tend to take three hours with a debugger to figure out. Especially perl has a tendency to work this way in my experience, as the RSA example further illustrates.

    On the other hand, copy-pasted code is almost the perfect example of non-compactness, and in that regard, compactness is highly desirable and generally improves maintainability.

    Ergo, I would claim that 'compactness' is not really an aspect in and of itself, merely an attribute of code that is supportable. Supportable code will have a high, but not too high, level of compactness.

    @blakeyrat said:

    None of those are what I'd consider most important, but of the three: Supportability, followed by Compactness, followed by Efficiency as a distant, distant last place.

    In high-performance applications, you sometimes have to take shortcuts. I too have written my share of code that was fast, but not easy to follow or understand.

    As an example: take quicksort. A lot of students have a hard time understanding how it works, the first time they see it. Bubble-sort on the other hand is easy, and in fact what a lot of new programmers do when faced with a sorting task (being the little blaggards that they are, they don't use the sorting methods available in their language of choice). But if you want performance, you will invariably go with the more complex version. Depending on the application and the task, efficiency can become almost as important as supportability.



  • @FragFrog said:

    But if you want performance, you will invariably go with the more complex version. Depending on the application and the task, efficiency can become almost as important as supportability.

    If you go the "supportability" route and use the sort function built in to your programming library, then suddenly, OH HEY MAGIC, you get the "efficiency" too. (And yes I saw your previous sentence but you admit it only applies to idiots which is what I'm interpreting the word "blaggard" to mean so I'm ignoring it on the assumption that people you hire to build an actual software product are not idiots also punctuation is for idiots)

    If anybody's writing a sort function for "efficiency", you work with idiots.



  • My answer would be "making your company money is the most important attribute of a program, and supportability is next most important because you want to be able to make money into the future. The other two don't matter at all unless they measurably impact the first attribute."

    I mean yes in a perfect world we would all produce clean, artisinal code that runs in worst case O(N) time, but I can't count the number of times that's led to Yoda conditions everywhere and bullshit "optimizations" that don't actually speed anything up. Just make it clear, supportable, and above all ship it - we can talk about "compactness" or "efficiency" when you have concrete numbers that say A) it impacts customers and B) making this part x% faster will reduce the customer impact by y%.



  • @Weng said:

    This is exactly what we're looking for. Most often, this order is completely inverted. And the ones that invert it are also always the ones that completely miss the "No explanations. Just number them" part and blab on and on about why they're right.
    Since I seem to have come up with the "correct" answer, let me at least offer an explanation for why I came up with what I did and why someone else might come up with a different answer:

    X is more important than Y if you'd be willing to increase X at the cost of decreasing Y.



  • @blakeyrat said:

    If anybody's writing a sort function for "efficiency", you work with idiots.

    Of course. The example was just that: something to illustrate a point, not something you'd actually encounter in production. In the real world, the choice is rarely as black and white as all that; it is almost always a matter of choosing between implementations where one is perhaps a bit simpler and the other possibly a bit faster. Still, these kind of situations occur - in my opinion, it is the hallmark of a good programmer to choose the correct one. Sometimes that means rewriting a solution so the fast implementation is also readable; sometimes the fast implementation is actually the simpler one. And in some cases the performance gain is negligible and keeping your code clean is not worth the price - those dreaded premature optimizations we sometimes see featured on thedailyWTF.

    @Tacroy said:

    when you have concrete numbers that say A) it impacts customers and B) making this part x% faster will reduce the customer impact by y%.

    This depends a lot on what you are developing. If your CRM application is taking a few seconds longer to start up, eh, nobody will complain. But if your website takes a few seconds longer to load, that does significantly impact your customers. Google has been doing tests on this for years now, and they found significantly increased bounce rates when their search results took as little as half a second longer to load (hence why they show only ten results per page: any more would take too long). In fact, it is rumored that the speed of a website is an important factor in determining its pagerank. They even made a special developer info page with tips on creating fast websites. I'd be wary of any webdeveloper who does not care about speed, or say it is of little importance.


  • Discourse touched me in a no-no place

    @Paddles said:

    I'd actually question all three of your definitions, and possibly even give different answers depending on whether we were using the words, or the definitions you have given the words.
    Normally we don't give definitions, just when people are waffling. Especially compactness - when we do say "elegance" we aren't talking about the classical hacker elegance - just the kind of thing that the sort of half-arsed programmer who waffles with such an obvious "please tell us that you know how to write code that's useful in an enterprise environment" throwaway question thinks is elegant (for examples, see the frontpage of TDWTF)

    Also, swapping "compactness" for "elegance" would break most of our interviewees - because I swear to god 9/10ths of them are either from India or China and English isn't their first language (or even a serious skill). The word "compactness" is tough enough for most of them to swallow.

     

    And no, you pedantic dickweeds. We aren't hiring embedded developers. Our entire architecture is built around heavyweight SQL databases, XML and XSLT and runs in batch, not realtime. If efficiency were a real concern, we'd have to burn down our entire architecture and start over.



  • @Weng said:

    This is exactly what we're looking for. Most often, this order is completely inverted. And the ones that invert it are also always the ones that completely miss the "No explanations. Just number them" part and blab on and on about why they're right.
     

    @Weng said:

    Also, swapping "compactness" for "elegance"
    would break most of our interviewees - because I swear to god 9/10ths of
    them are either from India or China and English isn't their first
    language (or even a serious skill). The word "compactness" is tough
    enough for most of them to swallow.

    In this case, then, I'd say that the interviewing style for this question is a WTF. It's important for developers to be able to communicate effectively - which includes adding comments or asking questions when they perceive room for ambiguity or confusion, BEFORE they've sat down to give a solution. I'd be worried about any situation where my success depends entirely on "guess the answer I'm thinking of". If someone isn't strong in English, that goes double - asking me lots of questions might sometimes feel annoying or frustrating, but if it leads to better understanding between us then that's tens or hundreds of times better than them delivering code that might be compact, efficient, even supportable, but isn't fit for purpose.

    And no, you pedantic
    dickweeds. We aren't hiring embedded developers. Our entire architecture
    is built around heavyweight SQL databases, XML and XSLT and runs in
    batch, not realtime. If efficiency were a real concern, we'd have to
    burn down our entire architecture and start over.

    Hmmm, someone must have [i]really[/i] enhanced Adblock so it filters out crap. The only mention of (or even allusion to) embedded systems came from me, and I only mentioned it as an example where context affects answers, not to suggest your answers were wrong. In other words, I didn't see any pedantic dickweedery. If you're referring to me then I take everything back because it means I'm TRWTF.

     



  • @Weng said:

    - Efficiency. As in the resource footprint of the code on the hardware.
    - Supportability. As in how much work it takes to maintain, how buggy it is, and how traceable/auditable the data is.
    - Compactness. As in how elegant the code looks."






    Totally depends on the situation. I have written code where each of the different qualities would be top priority:



    1. Efficiency: some very highly optimized video processing code that simply wouldn't be fast enough if it wasn't as efficient as possible. I also wrote 50 pages bachelor's thesis on how it works, but even so it is hardly easy to maintain nor compact.



    2. Supportability: majority of large projects. I guess you wanted this as the first?



    3. Compactness: examples, small scripts, and also supportability often stems from elegant code at the low level.


  • @Paddles said:

    I imagine you could write a bogosort wth a tiny resource footprint - but is it efficient at achieving the desired outcome?

    Bogosort will never have a tiny resource footprint because CPU time (or processing power) is a resource, and usually the most important one.



  • I don't agree completely with your definitions either, but I would have picked:

    1. Supportability - how maintainable the code is, to reduce the cost of change effort.
    2. Efficiency - maintainable code that is a resource hog is something well-written but doesn't serve the intended purpose, but can be modified more easily than efficient code that's unmaintainable which people dread changing for fear of introducing inefficiencies. However there should be defined warranty targets - anything above this is efficiency for the sake of it and represents an unnecessary cost.
    3. Compactness - is purely cosmetic and has no bearing. Ugly maintainable code is better than a codebase that's elegant but over-sensitive to change. I'd take inelegant and efficient over elegant but inefficient. Yeah, I'd plump for the frumpy practical housewife over the trophy wife that's slow at everything. 
    Note I would have picked those in the absence of more context. For some situations the priorities will change - but I'd like to throw those questions at the client to determine how they prioritise characteristics of the finished product.



  • @Weng said:

    Normally we don't give definitions, just when people are waffling. Especially compactness - when we do say "elegance" we aren't talking about the classical hacker elegance - just the kind of thing that the sort of half-arsed programmer who waffles with such an obvious "please tell us that you know how to write code that's useful in an enterprise environment" throwaway question thinks is elegant (for examples, see the frontpage of TDWTF)

    I would have thought compactness / elegance would have been a part of supportability. Though overly compact code can detract. I definitely would have rated that last.

    @Weng said:

    Our entire architecture is built around heavyweight SQL databases, XML and XSLT and runs in batch, not realtime. If efficiency were a real concern, we'd have to burn down our entire architecture and start over.

    But of course, there are the stories about daily batches taking 25 hours. And when dealing with heavyweight SQL databases, writing good (efficient) queries becomes really important. Sure, you're using a bunch of stuff that isn't known for blazing speed, but that's not a reason to make it worse. I'm also thinking about how expensive (and therefore scarce) the resources are for you from an internal procurement standpoint, which says that some additional efficiency would be a good thing. Anyways, more than having "compact" code.



  • @Weng said:

    Our entire architecture is built around heavyweight SQL databases, XML and XSLT and runs in batch, not realtime. If efficiency were a real concern, we'd have to burn down our entire architecture and start over.

    If that's really the case, then supportability and compactness aren't real concerns either. Infact, I'd say a pipeline built entirely around XML/XLST and a mountain of SQL stored procedures is the poster child of unmaintainable, unreadably verbose resource hogs.

    Do your interview candidates get to hear about the architecture and technologies used during the interviews? While that kind of architecture was acceptable in the late 1990s / early 2000s during the XML boom, I doubt a competent hire would even stick around for the interview if you dump that kind of a turd on them nowadays. (Not really a problem though; you're hiring Indians and Chinese with barely any communicative skills in English, meaning they pretty much have to take what they can and work the shit-tier of jobs.)

     



  • @FragFrog said:

    But if your website takes a few seconds longer to load, that does significantly impact your customers. Google has been doing tests on this for years now, and they found significantly increased bounce rates when their search results took as little as half a second longer to load (hence why they show only ten results per page: any more would take too long).

     

    That's why I specifically said you need to have concrete numbers. Google has concrete numbers, so it makes sense for them to optimize the things their numbers say they should be optimizing.

    On the other hand, I've seen code horribly mangled in the name of "speed", ripped it out and put in a maintainable, non-"optimized" implementation, and not slowed things down at all because the part that was actually dragging everything down lives in a completely different part of the code.

     



  • I'd say Compactness drops off the goddamn list. It's completely irrelevant. Any good property of code one might put under Compactness is in fact part of Supportability.

    Compactness is a vague term. It can mean that I separate functionalities into methods so that the main entry method has just a bunch of function calls with self-documenting names, which is really compact!

    On the other hand, you have those cowboys that use ternaries everywhere because "one line is more compact and elegant".

    Given the variety in answers here for the second and third option, I think your list has definition problems.

    @Weng said:

    Also, swapping "compactness" for "elegance" would break most of our
    interviewees - because I swear to god 9/10ths of them are either from
    India or China and English isn't their first language (or even a serious
    skill). The word "compactness" is tough enough for most of them to
    swallow.

    Heh, it seems that the problem is your interviews, not the interviewees.

    "So what do you think of this random page of Kant's Critique Of Pure Reason?"

    "Que?"

     

    As a personal yardstick, I believe that re-writing my big javascript image-fader thing into something that uses jQuery and 20-30 lines of script is very compact and elegant. Of course, it has fewer features, so that's a tradeoff. I'm not here to play code golf, I'm here to make programs that do things that I hope make people less sad in this fucked-up world.



  • @Weng said:

    And no, you pedantic dickweeds. We aren't hiring embedded developers. Our entire architecture is built around heavyweight SQL databases, XML and XSLT and runs in batch, not realtime. If efficiency were a real concern, we'd have to burn down our entire architecture and start over.
     

    The fact that you consider that your question has a correct answer is a WTF in itself. Now, calling everybody that disagrees a "pedantic dickweed"... Take a look in a mirror.

    Not every environment has the same needs as your workplace.


  • Discourse touched me in a no-no place

    @Weng said:

    If efficiency were a real concern, we'd have to burn down our entire architecture and start over.
    Burning everything to the ground and starting over is sometimes a very tempting option, but it's often a mistake at the business level. It takes ages. Always. (Well, unless the code is trivially short or totally obsoleted by something else that's damn close.) During this time, you're not adding value to the system: you're trying to build up to having the same value you had before.

    The only time it is justifiable is when starting over lets you get a lot further than before or greatly reduce your ongoing support costs.


    It's ever so tempting though.



  • @blakeyrat said:

    None of those are what I'd consider most important...

    Pray tell, what would you consider important? Font?



  • > Efficiency. As in the resource footprint of the code on the hardware.


    If the code is in the critical path then 1st else 2nd.

    > Supportability. As in how much work it takes to maintain, how buggy it is, and how traceable/auditable the data is.


    1st.

    > Compactness. As in how elegant the code looks."


    Irrelevant. Also, what has elegance got to do with compactness?

    > No explanation is needed.


    This is the point where I excuse myself. Not asking me for any explanation shows that you are just looking for someone who knows the answer to the trick question, not someone who knows how to do the job. Or perhaps you are simply looking for ego gratification that you are teh @w3s0m3 c0d3r who knows all the right answers?

    One line answers are for mass examinations (e.g. certification exams); one-on-one situations demand explanation and justification of answers.

    To answer the question posed at Blakey above, the most important attribute of code is "correctness". Weng asked us to just rank the 3 choices given, rather than all attributes, but I'd still be answering the question in the interview with a comment like "this is assuming the code is correct, right, because if the code isn't correct then other attributes are irrelevant.".



  • @veggen said:

    @blakeyrat said:
    None of those are what I'd consider most important...

    Pray tell, what would you consider important? Font?

    Code is the smallest, and one of the least important, part of the process of making software.

    Number 1 would be "fitness for purpose", that is, does the software do what it purports to do? And is that what the client wants it to do?

    Number 2 would be "usability", can the software be used easily and efficiently by the client?



  • @blakeyrat said:

    @veggen said:
    @blakeyrat said:
    None of those are what I'd consider most important...

    Pray tell, what would you consider important? Font?

    Code is the smallest, and one of the least important, part of the process of making software.

    Number 1 would be "fitness for purpose", that is, does the software do what it purports to do? And is that what the client wants it to do?

    Number 2 would be "usability", can the software be used easily and efficiently by the client?

    So to summarize: the important part of the program is not the part that makes it work, but the part that makes it work.


  • Supportability, efficiency, compactness.

    Though one could make an argument for compactness beyond the areas that overlap directly with supportability - the number of bugs tends to be correlated with the number of lines of code, so a shorter / more elegant approach may have fewer bugs.



  • @Ben L. said:

    So to summarize: the important part of the program is not the part that makes it work, but the part that makes it work.
     

    Blakey's point is about what it does is more important than how it does it. What you build, others consume - and often they're not bothered about the inner workings, they're placing value upon how it works for them.

    To come back to the crap car anology: customers aren't really that interested in how the vehicle was constructed: they want to know if it starts and if they can drive it comfortably. It's us "engineers" that are hung up about quick-release mechanisms for easy part swapout, less convoluted design to avoid the sprawl of tubes getting in the way and good performance being squeezed out of a smaller power plant. Customers are simply bothered about what cost it means to them.

    (Brings to mind the advert with a kid comparing a macbook against an intel-based laptop, conflating CPU clock speed with operational performance.)



  •  The only correct answer is that there can be no correct answer. It depends on what the program is intended for, budget, price etc. and will even vary as the program matures.


  • Discourse touched me in a no-no place

    So perhaps TRWTF is actually the question. I'll take it to the rest of the interview crew and see about adjusting it a bit. I guess the underlying problem is that I've been immersed in our environment for so long that I understand the peculiarities of our priorities.

    Thinking about dropping compactness, since it's partially subsumed by supportability and adding correctness 

     @havokk said:

    One line answers are for mass examinations (e.g. certification exams);
    Given another one of our bank questions is "When would you use a SQL Index?" and another one is "How do you know what indexes to create?" and the three most popular answers to both are "I don't know", "We had DBAs for that at my last job" and "Something completely bogus about making it easier for you to find files" (this 'files' thing comes up in reference to databases a LOT) we do lean a bit towards the "final exam" side of the fence. Yes, it's insulting to people who actually know what they're doing, but for all sorts of bogus reasons we can only afford to keep so many of that sort of people on staff, and we're full up on competant-but-expensive. We're trying to hire in the "passable but cheap" and "fresh graduate, shows promise, just wants enough cash to move out of mom's basement" brackets. 

     @havokk said:

    but I'd still be answering the question in the interview with a comment like "this is assuming the code is correct, right, because if the code isn't correct then other attributes are irrelevant.".
    And I'd be making the "holy shit it's a professional!" squiggle on my notepad and glancing back to your agency cover page to see what your rate is (and then, probably, trying to figure out why they bothered submitting you when we told them how much we could pay).



  •  Isn't the "compactness" part of supportability?



  • @Weng said:

    Given another one of our bank questions is "When would you use a SQL Index?" and another one is "How do you know what indexes to create?" and the three most popular answers to both are "I don't know",
     

    That actually exceeds my DB experience.

    When would you use a SQL Index?

    When shit's slow. 'Slow' defined as when actions that are not explcitly processing (like a photoshop filter or report generation) taking more than 1 second.

    Slow is also when explicit processing actions take more than 20 seconds.

    @Weng said:

    How do you know what indexes to create?

    I don't know. I really don't.



  • @Weng said:

    Thinking about dropping compactness, since it's partially subsumed by supportability and adding correctness 
     

    How about dropping the options and leaving the question open: "what are important characteristics of an application and why? Name three, recounting your experiences of them." ...?

    @Weng said:

    "When would you use a SQL Index?"

    Never heard of an SQL Index. I can tell you about table indexes, though </dickweedery>

    @Weng said:

    "We had DBAs for that at my last job"

    That rings major alarm bells to me... not only that they have no experience (do you list that on the job requirements, BTW?) but also indexes being created by DBAs shows their previous employment didn't match responsibilities to roles properly. So this "developer" could amount to nothing more than supporting Office applications and writing Word macros.@Weng said:

    We're trying to hire in the "passable but cheap" and "fresh graduate, shows promise, just wants enough cash to move out of mom's basement" brackets.

    Pay peanuts, get monkeys and all that jazz.@Weng said:

    and then, probably, trying to figure out why they bothered submitting you when we told them how much we could pay

    Ah. You had that part covered.

     

     

     



  • @dhromed said:

    @Weng said:

    How do you know what indexes to create?

    I don't know. I really don't.

    1. Steal Cassidy's comment about there being no such thing as a "SQL Index". I hope the actual text is phrased correctly... unless it's supposed to be a trick question.

    2) The answer I'd give, which I'm certain is not the one Weng is looking for, is I'd run the SQL Server Profiler during the long query and implement whatever indexes the query optimizer suggests. Sure, I know from college you can work it out on paper, but running the Profiler is like 50,000 times quicker and the answer it comes up with is going to be the correct one 99.9% of the time.

    This is of course assuming Weng's company isn't using a shitty SQL without any development tools. In which case, I suggest if they're doing professional software development they use professional tools.



  • @Cassidy said:

    @Ben L. said:
    So to summarize: the important part of the program is not the part that makes it work, but the part that makes it work.
    Blakey's point is about what it does is more important than how it does it. What you build, others consume - and often they're not bothered about the inner workings, they're placing value upon how it works for them.

    That's pretty much exactly it.

    But even on a more practical level, unless you're making shitty products for customers who don't exist, or perhaps you're some sort of software savant like Bill Atkinson, I can almost guarantee even right now you're ("you" meaning "people assigned to your software product") are spending more time on gathering requirements, doing usability testing and QA in general, localization, assets, general janitorial tasks (like merging code) and etc. than you are writing code. You might be in a position where you're insulated from the real work at your company, but believe me: that other stuff is happening. (Or, alternatively, you work at IBM on the Lotus Notes team and your product is a complete disaster.) The only way you might think otherwise is if you're maintaining a 10-year-old app and all that stuff was front-loaded and all you're doing now is maintenance-- but even then I bet you spend more time on non-code tasks than code tasks.

    Hell I spend my days writing a data processing back-end for a web analytics product. Nothing at all user-facing. Do I spend the majority of my personal time writing code? Not even close. And this is the by far most code-y part of the product.



  • 1) Sustainability

    2) Efficiency

    3) Compactness

    Reasoning being that if the code "looks" elegant isn't a major concern, but the code needs to be readable and testable and the like which is covered (I think, anyways) by Sustainability; code that is easily maintainable is by default elegant code.

    However the Real WTF is as someone else said having systems based around SQL and XML and huge stored procs.  Get with the times; this shows ignorance and a lack of forward thinking progress.


  • Winner of the 2016 Presidential Election

    @ObiWayneKenobi said:

    1) Sustainability

    I, for one, only use code classes from clean, renewable sources.



  • @blakeyrat said:

    @dhromed said:

    @Weng said:

    How do you know what indexes to create?

    I don't know. I really don't.

    2) The answer I'd give, which I'm certain is not the one Weng is looking for, is I'd run the SQL Server Profiler during the long query and implement whatever indexes the query optimizer suggests. Sure, I know from college you can work it out on paper, but running the Profiler is like 50,000 times quicker and the answer it comes up with is going to be the correct one 99.9% of the time.

    This is my preferred technique, but it does require that the query actually complete. And, if the query takes longer than a minute to run, I lose patience quickly and kill it. Sometimes the "Guess what the query plan will be if we try to run it" button (I guess some people call it the "Display Estimated Execution Plan" button) works too.



  • @pkmnfrk said:

    @blakeyrat said:

    2) The answer I'd give, which I'm certain is not the one Weng is looking for, is I'd run the SQL Server Profiler during the long query and implement whatever indexes the query optimizer suggests. Sure, I know from college you can work it out on paper, but running the Profiler is like 50,000 times quicker and the answer it comes up with is going to be the correct one 99.9% of the time.

    This is my preferred technique, but it does require that the query actually complete. And, if the query takes longer than a minute to run, I lose patience quickly and kill it. Sometimes the "Guess what the query plan will be if we try to run it" button (I guess some people call it the "Display Estimated Execution Plan" button) works too.

    Yes. You already know the query is a dog. It's usually easy to spot the reasons, because you're doing full table scans. Of course, when this is still happening after you have an index, you have to actually start thinking about the problem.



  • @Weng said:

    Thinking about dropping compactness, since it's partially subsumed by supportability and adding correctness 
    So then it would go 1) Correctness, 2) Sustainability, 3) Efficiency?

    Not being a DBA:

    @Weng said:

    "When would you use a SQL Index?"

    When I need to query based on the index.@Weng said:

    How do you know what indexes to create
    Hopefully thinking about the use-cases for what gets queried on and how often, but also a profiler.



  • @dhromed said:

    @Weng said:

    How do you know what indexes to create?

    I don't know. I really don't.

     

    At the risk of hopping in with further details when you weren't actually asking for one...

    • indexes speed up searches but slow down transactions - so tables biased in favour of reads over writes are candidates for indexes (lookup tables, catalogues, etc)
    • an index, once created, doesn't formally get used by the user - the database uses it on their behalf, so it's invisible to the user
    • some indexes are automatically created - any unique column will have an index (including a Primary Key)
    • which columns in the tables to index can be determined by tools that analyse what's being hit the most (some tools - such as Oracle Perf Tuning pack actually run periodic analysis and suggest ways of improving data access)
    • adding indexes to table columns does bugger all in some situations - such as the dataset being small (fitting into one DB block), binary ranged values or the required rows com[rising more than 51% of the table
    • before adding an index, taking a performance baseline enables a benefits comparison.

     



  • @Cassidy said:

    At the risk of hopping in with further details when you weren't actually asking for one...
     

    I am always asking for more details.


  • Winner of the 2016 Presidential Election

    I create indices on whichever sets of columns I frequently join by or order by, if they're not part of a key already.

    Now someone tell me why this is bad.



  • @dhromed said:

    I am always asking for more details.
     

    Yesss... it's just the way you stroke that white cat slowly whilst maintaining a knowing half-smile that's somewhat unnerving and puts people off, y'know?


  • Discourse touched me in a no-no place

    @Cassidy said:

    To come back to the crap car anology: customers aren't really that interested in how the vehicle was constructed: they want to know if it starts and if they can drive it comfortably. It's us "engineers" that are hung up about quick-release mechanisms for easy part swapout, less convoluted design to avoid the sprawl of tubes getting in the way and good performance being squeezed out of a smaller power plant.

    Those of us who can't or don't want to buy new cars every 5 years do care about this, because it has a bearing on maintenance costs. (Or have you never had to pay $300 in labor costs to get a $15 part replaced?) Similarly, more enlightened companies do care about software construction techniques to the extent that they affect maintenance costs.



  • @PedanticCurmudgeon said:

    Those of us who can't or don't want to buy new cars every 5 years do care about this, because it has a bearing on maintenance costs. (Or have you never had to pay $300 in labor costs to get a $15 part replaced?) Similarly, more enlightened companies do care about software construction techniques to the extent that they affect maintenance costs.

    I know you're probably in a time-warp, but the rest of us live in a universe where even the cheapest cars go 150k+ miles without any maintenance (other than scheduled of course.) What car are you talking about? Some 1974 AMC shitpile?


  • Discourse touched me in a no-no place

    It's a 2006 PT Cruiser.



  • @PedanticCurmudgeon said:

    It's a 2006 PT Cruiser.

    My 2004 PT Cruiser is rock-solid. So maybe you just drive like an idiot or filled your oil reservoir with apple juice or some shit. Why'd you do that? Oil goes there. Apple juice isn't oil!


  • Discourse touched me in a no-no place

    You're not as funny as you think you are.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.