Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I saw this quote in this question:
MS support is poor, except when you've
paid for a support contract... then
its very very good. – gbjbaanb
This got me thinking. My company has had 2 support incidents with Microsoft a few months ago (before Stack Overflow was live). In both cases, we were pushing the limits of the SharePoint system we were building, and the API did not expose events to let us know when operations were completed. Both times, Microsoft's response was to tell us to add a Thread.Sleep() call and just wait for the operation to finish.
Now, I am all for the community working together to answer questions, but sometimes there just aren't answers to your question available online.
For the times when you can't find an answer, has paid support been worth it to you?
If you have had success with Microsoft paid support, please share what type of problem it was. I am trying to understand exactly what to expect from a support incident.
Yes it has. If you have made an effort to solve the problem yourself, you have to get to at least the third person before you get anybody who will understand the issue, and maybe the fourth person can help.
Once you get to that person, though -- I've found the support to be unbelievably good with a lot of followup and I even had an MS support person help me solve a complex ASP.NET deployment issue with one of our customers.
It's been mixed.
If you get lucky and talk to the right person they can provide invaluable insight.
On the other hand you might end up with another sympathetic pair of eyes. This can be helpful but not worth the money.
I too have had a good experience, but as with some of the others I will say that you have to escalate the issue typically to get resolution. Once you do though, they follow-through very well, and provided detailed assistance.
I have had amazingly good luck calling MS for support. Usually, calling any large company for support is a nightmare. The exceptions, for me, have been MS and Oracle. In the case of MS, I have made 3 calls to them, 2 of which were IT related and one was a programming or Visual Studio related problem. Sorry I don't remember what the issues were. I recall having a little trouble understanding one of the reps due to accent differences between us, but he was very good and we got through it. This was about 3 years ago.
One other thing is I have found that the reps want to give you a break. If it is a bug, they won't charge you, and all the reps were very fair on this in my experience.
Yes, I have had an opportunity to use paid support from Microsoft. I was working for a dot-com and we were having intermittent crashes on our main site which used ASP. I had been asked to run this utility to generate a crash dump when the error popped up on the site and had sent a few in to be analyzed. The analysis suggested that the number of string concatenations being done in the code was a potential issue as this was causing the memory to fragment and that led to the issue as the code had hundreds of concatenations, sometimes where the code didn't even need to do it, e.g. in a line there would be " blah blah blah " & " more more more" where the & is unnecessary and causing part of the issue, as well as suggesting that a string array may be better for handling taking string after string to build part of the response for some pages.
I've only had one experience with Microsoft support, and in that instance I found it to be lacking. After a few hours on the phone they concluded that there was no way to solve my problem (unable to modify any website settings in IIS) and we would have to reinstall everything. I later found a way to fix it myself without going through all of that by manually editing a file. This was about 8 years or so ago though, I haven't had to deal with them since then.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are starting to adopt agile in a project we are about to begin.
Although I am not actually involved in the development of this project, I am involved in the stand up meetings.
Is it acceptable to say how you are learning a new technology (eg C# 4.0) as one of your tasks, alongside the actual deliverables?
My task is constant everyday so it is embarassing to say how I am doing the same thing (which is not a fun task - more admin type) while the other team members are doing C#/ASP.NET - the fun stuff. This obviously dents my morale.
How should I approach these meetings?
Thanks
Is it acceptable to say how you are
learning a new technology (eg C# 4.0)
as one of your tasks, alongside the
actual deliverables?
Learning time is legitimate, and if the company sees it that way you can make it a task.
Full disclosure: although the company I work for sees learning as a part of the process of software development, I don't actually put individual learning tasks into my weekly reports; I just build it in as a part of the larger development task.
My task is constant everyday so it is
embarassing to say how I am doing the
same thing (which is not a fun task -
more admin type) while the other team
members are doing C#/ASP.NET - the fun
stuff. This obviously dents my morale
Where I work the people that have ongoing "areas of achievement" list the individual tasks they achieved when we meet each week. Some of these tasks can be quite mundane, such as "I went to this meeting," or "I ran this script that took 2 hours," or even, "I read this chapter of that book because I needed to know how to do this." Our company understands that this is the nature of the work. You shouldn't be embarrassed about this.
Full disclosure: I break my "areas of achievement" into smaller goals that can be completed in roughly a week's time, so that each week I can say that I completed something.
I'd try to embrace the three questions:
What did I do yesterday? (Did you
learn about some of the dynamic new
features of C#?)
What are you going
to do today? (Do something with what
you have learnt that challenges you)
What is impeding you? (If you lack a
skill look to the senior guys to
help teach you.)
Kindness,
Dan
Suggest that you are a "chicken" in the process, which is an agile term for being an observer to the meeting but not a participant. http://www.agilejedi.com/chickenandpig
Since you consider your present task 'embaressing', I am assuming that you want some more development responsibility.
In my opinion is the stand up is probably a good time to ask for this.
I suggest that you say something passive like: before the next standup I will try to put what I have learned thus far in C# 4.0 to good use within some area of the project.
You in short order, you will be given something to do... then instead of having nothing to say during the stand ups, you will be too tired to go to them.
be careful what you wish for... because some day, you might get it.
As a junior, you're expected to learn. So, unless you feel admitting to learning would imply you're not doing your other tasks, I say go for it.
You can still report what you learned yesterday, what you plan to learn / try out today, and if you have any blockers that are preventing you from learning.
You will not spend the whole career as "Junior" (and everyone too). How do the team know that you can do higher responsibility? of course by showing that you're capable of. As it's Agile meeting, I believe everyone will have chance to show his idea.
Do your best to answer questions and show your "out of the box" idea to the team.
One day once they think that you can handle higher responsibility, you will out from your current position to more challenging works.
Learning/knowing something doesn't show that you can use it. There are some way to let the team know about your C# 4.0, by talk about it at lunch, writing on your blog then let your team know, write some tool for your daily tasks, etc.
Not only on the meeting :-)
Good luck!
Where I work, we do have people that will say in the stand up that their day will be spent on non-project work as the stand up is for a specific project that almost everyone speaking in the stand-up has a part.
If you repeat the same task a few days in a row in stand-up, you may be asked why you are taking so long on a card, if you have enough resources, etc. as there may be some thought that you are off on a tangent or spike.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm interested in evaluating bug trackers, but I wanted to back up and figure out what sorts of criteria were most important in bug software. So far things I've thought of include:
integration with source control
usability
basic features (email notifications, rss, case states)
customization
advanced features (reporting, visualizations)
stability
cost
IDE integration
Any ideas?
Ease of use
This should, in my opinion, be on the top of your list of features to evaluate against. You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
A tool that has 15+ fields on the screen, where 10+ are required in order to just be able to submit the issue, is not such a system. With such a system, you'll get postit notes from testers to developers about the little things.
When evaluating BugTracker X, which bugtracker do the developers of BugTracker X use?
customizable workflows (from "open" to "in work" to "resolved" to "closed")
fine granular access control
There was a recent thread on Hacker News about this exact question. Lots of good stuff in there!
An API. Mandatory.
You MUST be able to catch and automatically submit bugs into your bug tracker from applications running in the field.
(Copy/Pasted from "Lasse V. Karlsen"'s answer)
You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
Even good, conscientious testers, if they are focused on testing component A but happened to stumble on a bug in component B, might not actually enter that bug if there is a lot of friction in the bug tracker. Friction means, required fields. It's not that the testers are bad or lazy - it's just how the human mind works. We focus. We don't see the guy in the gorilla suit.
The Joel/FogBugz philosophy of NO required fields is the right one (Also the philosophy of my own BugTracker.NET). You almost always can gather the details later - what os, what version, what browser, etc.
Also, take a look at "Bug Shooting", if your app has a GUI. You want to make it as easy as possible for the testers to take a screenshot and get it into the bug tracker, and that's a great tool for it. Pick a tracker that works with Bug Shooting or has its own dedicated screen shot tool.
Distribution. My version control system is distributed, why shouldn't my bugtracker? If I fix a bug on the train, why should I be able to make the fix but not record it?
Probably everything mentioned by others, plus some from me.
If you have long term big project, separate testing team that will do functional tests, you should take few additional things into consideration:
- can bugs be linked to test cases (and more precisely to given run)?
- can defect tracking system exchange data with test management system?
- can it produce (useful) reports?
- can bugs be grouped by release?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
While this doesn't apply to my present situation, I'm sure we've all been there before. You're a Java developer who's been asked to develop an app in C#, or you're a ASP.NET developer asked to do something in ASP.NET MVC, or a PHP developer with the opportunity to do a Rails or Django site.
Fundamentally, if you're a competent programmer, these sorts of platform shifts shouldn't really be a problem. Given enough time, you can expect to become as proficient as you were on your old platform.
However, if this is a freelance project for a client, does it seem at all unethical to be learning this platform on their dime? Assuming said client doesn't give you an unlimited amount of time to finish the project, there are going to be compromises and possible quality issues due to your inexperience.
That said, you have to start somewhere and not everyone has the luxury of spare time to tinker with new languages/platforms. Sometimes its necessary to just bite the bullet try and plan things intelligently and just get it done and get paid.
Does this seem unethical? Would accepting a lower rate make it more ethical?
I see no ethical problem here if you disclose that your primary expertise is on platforms other than the one that they're hiring you to develop on.
Assuming you're billing hourly:
If you're an experienced developer then you should be able to tell what is costing you time due to learning the new platform versus solving the problem at hand.
Keep track of what you do (using a screencap application could help here) and if it's pure research (reading articles, looking up documentation) then don't bill it. Also, if you're fixing a bug that turns out to be a newbie mistake (such as misunderstanding some information), then don't bill that. The rest of your time will have been spent in productive work for the client, and that should be what is billed.
It sort of goes without saying, but your client would be the one to determine if they even want to go with you as a consultant if you don't know the language/platform they want you to work on, and they would also be the ones to tell you whether or not they will pay for you to "learn as you code". You just need to be upfront and honest with everything from the start. Don't act like you know a platform/language if you don't.
No - its not unethical. Our profession demands that we learn something new on a constant basis. This is why we can be expected to charge / get paid what we do. Employers are often willing to not only buy books for us, but also pay for certifications, seminars, and any time we spend at said extended learning. The rationality behind it is that if we learn something new, there is inevitably a payoff for them (be-it efficiency, performance, etc).
I suspect that you'll argue that its different because you are freelancing so I'll pose the question - why is it any different? Your employer is your client - if you feel that they'll gain benefit from said platform over another then you are doing them a service and should be compensated as such.
It sounds like you're all talking of "Time and Materials" projects where the client pays you however much time you take to complete the job. On a project like that I can see how this comes into play and I would recommend being honest.
Most of the projects I work on are "Fixed Price". The customer gives us an idea of what they want. We then work up a "Fixed Price" quote. If the customer doesn't like the numbers they go elsewhere, if they're ok with the numbers then they agree to the price. Whether we have to learn something to get the job done or not the customer's price remains the same. In this situation it doesn't matter. The customer either agrees to the price or not and it doesn't matter how much time it takes you.
I've been in a situation like this with adobe air. Yes it's not exactly like jumping from Java to .NET or from PHP to Python since I already knew javascript. Actually I was affraid that I'd come off as too expensive and gave a below margin price for the project. But didn't regret it because the client was very satisfied and returned with another 2 projects later.
If the price you offer is acceptable to your client and you are absolutely sure you can deliver a high quality product there's nothing unethical with it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I spent a lot of time recently reading about debugging. One of the aspects that was continually referenced was not just a bug-tracking system, but a bug-solving process. I read about people writing down takes on the problem(that did or didn't work), tests that would determine if a given take on the fix would work or not, etc.
So I am thinking, "hey, this is a good idea"
I use Mantis right now, and it doesn't seem to have that capability(without abusing its fields). Mantis works great as a bug logger. But I'm looking for something more sophisticated in interface, I think.
Example
Suppose my bug was "Pants fall off". Then I want to log this information as...
"Pants fall off; Feb 32, 2009, 25:61; when I walked into a room, my pants fell off!"
Developer 1...
Hypothesis 1: Pants too big.
Test 1:Put on a belt.
Possible Solution 1: Buy a belt.
Result = ?? Result ???
Test 2: Put on your kid sister's pants.
Possible Solution 2: Steal into her room and take all her pants while she's at school!
Result = ??, date/time = ???
Developer 2...
Hypothesis 2: Your pants have holes in them.
Test 1: Shine a light on them.
Possibile Solution: Buy new pants.
Result = ???, date/time = ???
Now, this is a silly example. But I think it would be great to have as a software tool.
Does such exist, and if so, what's it called?
Trust me: you really don't want to maintain your bugs, that's why you don't find "Bug Maintenance Systems" :-)
Sorry... couldn't resist. Regarding the actual content of your question: I personally just keep track of all that information in the comment history of the ticket. Mostly I use trac for its simplicity, but also the capability to link into sources if required (at least on the file level, I wish it would grok code so you can point into the AST).
You could use Testopia, which is an extension of Bugzilla. This, of course, would also mean you would need to use Bugzilla.
Taken from the Testopia website:
Testopia is a test case management extension for Bugzilla. It is designed to be a generic tool for tracking test cases, allowing for testing organizations to integrate bug reporting with their test case run results. Though it is designed with software testing in mind, it can be used to track testing on virtually anything in the engineering process.
We also use Mantis, and like Peter Becker describes, we use the comments to describe the work on a bug. This usually works, because most bugs don't have such a long history.
If work on a bug becomes so complex it needs its own meetings and meeting notes, we usually create a task in our main work planning system and do the discussion there (linking from Mantis). That at least works for us.
At any rate, I'd be wary of a system that tries to explicitly support a certain workflow, as these also tend to lock you into the workflow they expect. An in bughunting, the workflow can vary a lot from bug to bug...
Finally, note that Mantis also lets you edit your comments. So you can change old comments to avoid cluttering the bug report.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I found a lot of questions asking for the best tool, but none asking for the features, you really need? And what features you never really needed?
(I caught myself to be comparing tools on feature matrices. Something I hate, because in the end I will be using only the 3-4 most important features and leave the rest untouched.)
It need to:
collect bugs
order bugs on priority/severity/due date etc
assign bugs to developers
track a bug history
link similar bugs together
link bugs to customers
link solved bugs to releases
provide enough information or a reference to get the information to reproduce the bug
usable by more than one developer
bug status need to be accessible by the client that reported the bug.
And there are more.
Simple end user data entry. Without this you won't have bugs entered, which equals worthless bug tool.
I can't answer this question for you, because I can't predict what is important for you, or what your situation is:
Are you on a large or small development team, or are you a one-man shop?
Would it be useful to have a system in place where you could have your application automatically send in trouble reports that create incidents in your bug tracking software?
Is being able to predict a release schedule important, or is this just something for a side project you're doing in your spare time?
Is integration with source control important?
In reality, you're the only one who can answer what features are required for you.
Those are the 3 must-have features I find most important:
Web interface so people can follow-up
Source control integration, otherwise it's really hard to track who did what and deploy patches
Configurable workflow with email notifications
Things I would really like to see:
1) Voting - i.e. how many customers/users does this bug hurt?
2) Severity/priority/whatever - the distinction between these terms is subtle and normally (IMHO) insignificant, but you have to have some idea of how important the bug is. Most tools have this, but overcomplicate it.
3) Dependencies - both internal (on other bugs in the same system) and external (external libraries, software, etc). Most bugs have this in reality, but it's not normally expressible in the database, leading to long, pointless debates at triage time.
Things I think are largely pointless:
1) Any extensive questionnaires - any bug-tracker that asks too many questions will just get bad data. That's worse than none.
2) Controversial, but compulsory daily/weekly/whatever email notifications. They just get filed as spam/ignored/filtered out. If developers should be fixing bugs, and aren't, that's a management problem. Software cannot fix this.
Need:
Email notification.
Status
Group notify
Group rights
Web interface
Easy / fast interface