Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I don't code any new features as long as there are some unfixed bugs in my software.</p> <p>The only reason I can think of to let a bug unfixed in my software is that it's definitely to costly to fix. In this case, we may choose to change this from 'bug' to 'known limitation' or 'known bug', and we fix the feedback we give to the user accordingly, so that the user knows exactly what's going on and why it's not fixed (see my edit below)</p> <p><strong>So typically, I spend all of my time bug fixing as long as the QA is complaining about something</strong>, and all of my time coding when it's not ! :)</p> <p>I do that because :</p> <ul> <li><p>When a software does a lot of things, but crashes randomly, the user will get a feeling that he cannot rely on the software, and there's NOTHING you can do to fix this. ever.</p></li> <li><p>When a software lacks some features, but is good at doing what it does, the user rather thinks "That may be a great software, too bad it doesn't support X and Y... I'll check the next release in 6 months". </p></li> </ul> <hr> <p>Joel Spolsky has written an interesting post on that question in his <a href="http://www.joelonsoftware.com/articles/fog0000000043.html" rel="noreferrer">12 steps to better code</a>.</p> <hr> <p><strong>Edit to answer comments :</strong> If I'm experiencing random crashes, that's definitely a bug, not a "known limitation". Once I know exactly what is going on, and only then, I can decide whether I can fix it or not. </p> <p>I was rather thinking of the following situations :</p> <ul> <li><p>the bug is provoked by code that doesn't belong to me (typically a third party library). If implementing a workaround is very complicated, it might be OK to wait for the third party vendor to fix it. Real world example : Clickonce doesn't work in some proxy situations... I expect Microsoft to fix it, eventually.</p></li> <li><p>If the bug is that a specific feature doesn't work in all situations, and that this feature is too difficult to implement for those specific situations, I think it's ok to warn the user <em>before</em> he uses the feature that what is trying to do is not implemented, rather than just crashing.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POImplementing features vs. bug fixing
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBrann
    1. USBrann
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POImplementing features vs. bug fixing
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis is not practical. Have you ever been working on a huge software project? It's nearly impossible to fix every bug before releasing. In my opinion it is okay to leave some bugs unfixed as long as this is documented and the bugs are of low priority.
      singulars
      1. PO
      1. USThomas Koschel
    2. COI agree with koschi, it depends upon the priority assigned to the bug.
      singulars
      1. PO
      1. USNaveen
    3. COAgree with the above commenters. Great as a stand to take, but unworkable in the real world, and you agree to it by yourself in the 2nd paragraph. Dressing an elusive crashing bug as a "known limitation", especially if it occurs randomly, sounds like a fishy practice.
      singulars
      1. PO
      1. USMaxVT
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload