Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I began using a bugtracker (www.bugnotes.com) so I am new to this... And I am easily adding bugs, makes sense. However some of these bugs would be fixed if I were to implement a given feature or perform some refactoring. So how can I track todo-list type things effectively, and don't these kinds of tasks tie into bug tracking? I guess what I am asking for is tool that tracks both bugs and features since they are all code changes.
Oh and putting minor fixes as #TODO or //TODO: is great actually, I like this for minor things, just not big things like refactoring, or changing a driver or a library.
Also, I was using a text file but the problem with that is that so much of what is typed into there becomes old and therefore the whole thing is kind of useless to me.
Any bug tracking system can be used to log bugs, features or general to-dos, as each is comprised as some form of work unit. The advantage of storing these in a bug tracking system is that all outstanding tasks are visible and can be prioritised. If you rely on TODO in the code then it is difficult to see these at a glance and hard to prioritise or see where you are with them. As a result, in my experience if you rely on TODOs then the list of these only ever gets longer. If you have some code that is incomplete, I think it's better to turn the TODO into a bug entry and then replace the TODO with the bug id, so you have a link between the code and the bug. A side benefit is that when you actually do the work and commit to version control, you can also add the bug id in the checkin notes and so you've got a permanent record of when the change was made.
If you have lots of TODOs already then it may be worth looking at a Hudson continuous build system, and add the Static Analysis plugin, so that you'll get a daily graph of the number of remaining TODOs, cross referenced with the source. That will at least present everything in one place and give you a burn down graph as you fix each TODO.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I want to write a bot for 500px.com which automatically likes pictures and follows random people. Sadly I don't have a clue where to start, are there any good tutorials or something? I googled, but could't find anything useful really!
I work at 500px. We'd really rather you didn't try to game the system, it hurts the community when you do and isn't fair to other users.
I mean, I'm a developer, I get that this might just be a curiosity thing for you. Maybe you just want to see what you can do. But maybe your efforts would be better spent, say, playing with our REST API.
But if it is that you're just trying to get more exposure, I hope that you'll reconsider your strategy. Focus your efforts instead on contributing meaningful content, engaging with your fellow users, working on your craft. When you game the system, you're advancing yourself on the backs of other photographers. The more people that engage in this sort of behaviour, the harder it becomes to find meaningful content, and over time everyone suffers.
No
Your problem is concept -- you want to write a automatic function that acts as if it is a human entity. This means that even if this is desired by the company behind the http://www.500px.com website, this does come across as something impersonating a valid human user, and as such will need to face and overcome the usual challenges of such thing as filling in online forms, logins and verification methods automatically and reliably without being detected as a 'bot .
This is potentially a very significant undertaking, and not to be underestimated. By posting this question on stack overflow you're pretty much giving away that you've very likely not got the basic skill-sets required for carrying out this task.
If this task is however in partnership or for the company behind the 500px.com website, then you will have access to very specific and first hand information about the details and website code and structure they use.
Both of the above conclusions - to me - imply that you're far below the very-probably required level of knowledge and you're going about finding that knowledge in entirely the wrong way.
Instead, find a programming language of your choice and learn it inside out and upside down, then you'll have (slightly) more chance at doing something like this.
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're trying to implement some agile/lean practices in our software development, and one thing I've read is not to maintain a long "wish list", but to keep the product backlog as short as possible with detailed notes only about the things near the top of the list. I can clearly understand the reasoning behind this.
However, often we will have a case where a customer of a tester finds an obscure problem or edge case. We usually do some investigation to find the exact source of the problem so we know how serious it might be (e.g. could it affect other cases?) and often consider how we would solve it and/or what workarounds are available. In some cases we don't go through with the actual fix because we think the cost/benefit isn't worth it at the time, but I still want to record the results of our investigations so that if the problem happens again in future, it's easy to recognize it and see what workarounds we used, and because we might decide that it's worth fixing it after all
At the moment we create a jira ticket with a special category called "wish list" for anything like this. Is there are more "agile" approach we should be using?
Be ruthless with your jira's, there is nothing to be gained by documenting every issue you find. Remember the agile manifesto - "Working software over documentation".
Fix the blockers right away, put the critical ones in the backlog and schedule in the next sprint, for anything that isn't worth fixing, do the investigation (always investigate bugs), write a few quick notes, and close it with the jira status 'wont fix'.
In Jira, or whatever tool you use, it is common Agile practice to close such a ticket with a closure reason of "rejected" or "answered". This will maintain the minimal documentation to prove that the issue was investigated but also communicate that the cost-benefit of pursuing the issue any further was not worth it. This backlogs then should be considered completed in any reporting roll-up and shouldn't distract the team during future backlog grooming or planning sessions.
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
I'm sorry if this is a duplicate, but the question search terms are pretty generic.
I work at a small(ish) development firm. I say small, but the company is actually a fair size; however, I'm only the second full-time developer, as most past work has been organized around contractors.
I'm in a position to define internal project process and policy- obvious stuff like SCM and unit-testing. Methodology is outside the scope of the document I'm putting together, but I'd really like to push us in a leaner (and maybe even Agile?) direction.
I feel like I have plenty of good practice recommendations, but not enough solid motivation to make my document the spirit guide I'd like it to be. I've separated the document into "principles" and "recommendations". Recommendations have been easy to come up with. Use SCM, strive for 1-step, regularly scheduled builds, unit test first, document as you go... Listing the principles that are supposed to be informing these recommendations, though, has been rough.
I've come up with "tools work for us; we should never work for tools" and a hazy clause aimed at our QA (which has been overly manual) that I'd like to read "tedium is the root of all evil".
I don't want to miss an opportunity with this document to give us a good in-house start and maybe even push us toward Agile. What principles am I missing?
EDIT 4/15 -
I might have been ambiguous about the scope of this document. For now, it's policy that my co-dev and I plan to follow. So far, we've been given free reign on choice of local tool, source control, etc, and the general process we follow in development (eg build, deploy, whether to use continuous integration...).
Ideally, I'd also like this document to be a model on which to base further process improvements. I'm mostly thinking QA, and maybe nudging our project management towards something lighter and iterative.
The Agile Manifesto and its principles might help with a few more ideas
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
The site I work with on a day-to-day basis has its share of shortcomings and we often make design decisions to "get us by right now" with the intention of fixing those up later.
I've found that making the time to actually go back and fix them, let alone remembering what the full list of to-do items is can be challenging at best.
Can you recommend any tools, resources or tricks that help you effectively manage your technical debt?
You could use any bug/task tracking software, eg see this stack overflow question: https://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool.
Of course, a simple solution is just to have a text file called TODO or similar. It's low maintenance, and particularly appropriate if it's a WORN file (write once, read never).
Unit testing
Refactoring
Continuous Integration
Planning (XP, Kanban, etc.) to avoid adding more technical debt
Standards
Code reviews
Project retrospectives
Static analysis tools (like FxCop) integrated with the CI build or check in process
I'd say TODO comments in the code, but my experience has been that developers generally ignore these.
I would suggest you add an item in your product backlog whenever you deliberately incur technical debt. This way, it is possible to consciously spend time during each iteration.
There is a plug-in for Sonar that you can use to find potential problems in your code base.
/Roger
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
When a large system developed by Agile process requires a sudden large-scale change that affects most everything, what is the best way to go about it using Agile? Does the iterative part change at this point?
For example, what if a decision is made to make a centralized system a distributed one? Or choose another large pervasive example.
Arguably large changes should have been planned for, but it's never a perfect world which is one of the reasons Agile exists, so assume that suddenly a major change is introduced that shakes the foundation.
Edit to summarize solutions:
It's incremental all the way no matter how large or small the change may be.
"Does the iterative part change at this point?"
Never.
No matter how "pervasive" the change appears to be, you still have to work incrementally, in iterations you can manage.
You still have to prioritize the changes and make them in a way that will continue to pass unit tests and can be released when needed.
You may, for example, find that fixing 80% of the system is sufficient, and you may release. Or may be required to fix 100% of the system before releasing.
You still work incrementally. In sprints. Irrespective of when you release.
Agile has no magic answers.
There's a number of approaches :-
Plot a path of reasonably incremental changes to change the system from one archtecture to another. If you have reasonably well factored code, you should be ditching the code that is made redundant by the change and keeping stuff thats independent of the change.
Another approach if things are really different, start a parallel development of components for the new system.
Or, start new and steal as much as you can from the old project.
Depends how BIG the change really is.