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 3 years ago.
Improve this question
I've come across a few different applications that monitor my usage while on the computer, but what have you used, and like? whether it be writing down your activities in a composition notbook or install an app that reports silently to a server? what do you like?
For explicit time tracking for projects I use SlimTimer. I also run RescueTime to track my time implicitly, but I end up not looking at that data very often.
I use neomem to keep track of things by hand. This allows me to keep track of more than just time. I often keeps notes associated with the story. This has become a collection of knowledge that I often search.
I use a paper timesheet to track my time. It looks like this:
(source: redbitbluebit.com)
and as a back up, I use a paid version the excellent TimeSnapper in case I need to go back and retrace anything I missed tracking the time on.
I prefer writing the times down using pen and paper. That way you can more fairly weigh things that would have been miscalculated if you were recording them with a stopwatch or timer.
If you start on something and have to get up for a few minutes, a timer may count that toward your working time had you neglected to stop or pause the timer. The good-old pen and paper are going to more accurately show which tasks you focused most of your time and energy on...not just the ones that you started earliest and ended latest. It may not be 100% accurate, but neither is the timer if you don't use it properly.
I have used both in the past, and find that there are problems with both, but I prefer the pen and paper method.
We use Standard Time as a Time Tracking tool and it's got a nice quick tasks window that is relatively small and lets you easily click checkboxes to switch between tasks. You can also create projects/customers and pre-set tasks to be loaded for each project (development, unit testing, documentation, etc...) and then just use the quick tasks window to switch which task you are currently working on without wasting too much time going through a full blown GUI.
It's not cheap - about $150/user - so if it's for personal use it might not be the best bet, but if you're looking for a solution for a team of developers then I've found it to be a good fit.
I use the time tracker plugin on Firefox. It tracks my surfing time of the whole day
I've been using Toggl for about a year now and I've found it to be spot on. It's simple to use and allows you to perform basic reporting against various criteria. You can either input time entries manually or use a stopwatch timer utility.
I tried out several applications before I settled on Toggl. For me, the intuitiveness of the Toggl interface was what decided it. I like my productivity applications to get out of my way and let me do my job and Toggl does just that.
There are various pricing plans, including a free one.
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 6 years ago.
Improve this question
I have a project which requires some complicated components built. Some of these components are promised by some obscure software packages which are proving to be poorly documented and difficult to configure and use.
I am wondering where other people draw the line during their software research phase in deciding whether to build their own packages or sticking with trying the existing packages?
And what percentage of the total project time should I spend on this kind of research?
Thanks in advance,
Alex
Ask yourself which is likely to take longer, hammering the components to fit your needs or writing your own.
Personally I pretty much always use solid, comprehensive libraries (jQuery for web development, DevExpress for WinForms) and fill in the gaps with my own code.
The only exception I remember off the top of my head was a tooltip plugin for a web application. I tried like 3, wasting hours and hours adapting each of them to my needs, even modifying their source code, playing with their images, fixing obscure css tags that baffle ie7 (cause ie8 defaults in ie7 mode on the intranet), but never quite getting it right, then just gave up and rolled my own in half an hour.
Not to say there aren't plenty of good components out there that are flexible enough to be used in active development environments, but you're unlikely to find them in the heat of developing your stuff with deadlines looming overhead. Use your free-ish time to look for them and bookmark them, try them out in a few toy projects and see how they work, so the next time you need something like them you know what to use.
If you have to fix some minor bugs or otherwise have to observe some patterns the code doesn't currently take into account, consider contributing back into the code base as a good citizen.
If you find yourself having to substantially recode some pre-provided code to get it to work, then maybe the fact it was already "coded" is irrelevant. Bite down and chew.
If it's bologna and you need to reinvent the "wheel", consider that you've got a job that may not be compensating it's actual value.
I usually draw the line at about 1/10. Meaning if it has already taken me, say, 1 day and I still haven't gotten the off-the-shelf thing working and it would only take me 10 days to do it myself, I do it myself.
Even when it takes a little longer, it's often better in the long run to avoid the complicated, hard-to-use thing. Or, at the very least, I get a better idea of what I really need and I can pick an off-the-shelf package with my eyes wider open.
Well i think it all depends.
Given that, it is possible for you to spend more time than u would have used for development at trying to configure and understand. I would say if you are good enough to create faster than learn the improperly documented on then go for it.
Else if the existing promises great features and will not take too much of the entire project time then go for it. Often it is very difficult to draw then line. It all depends on the situation at hand.
Also you could look for alternatives to what u have now.
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 have friends who have asked me to make websites and most are very small, usually I don't bother with a technical plan but one friend in particular clearly had goals larger than my own and the project is dragging on forever. If I had made a spec before the project I feel like this wouldn't have happened and our relationship would be as solid as before.
So my question is, how can you tell how small is too small? How do you tell when the project you're embarking on is going to end up in a guilt-ridden scope creep nightmare?
If you are going to be charging money (or don't want to be stuck doing the project forever), a project plan is always a good idea. Even if it's just a one-pager outlining what the web site will have (how many pages, any special features) and who is responsible for what. You should factor in that you'll spend 20% of your time (or whatever percentage past experience has taught you) on documentation or non-coding type work, you can give a better estimate of the effort needed. If it's a friend, you might want to tell them that you'll do the first X hours for free, but after that your rate is $Y per hour. Also, keep an accurate log of the time you've spent so that you can show them the amount of effort that is involved. Also, keeping an accurate log helps you estimate future projects.
As you may have already figured out, no project is too small to have at least an informal, written plan. Even if it's just a features list.
A project that does not need a plan is a project that does not need to be even started. In my opinion everything needs a plan, what changes is the extent of that plan. A plan could be just a list of deliverables and some deadline attached to each one. A more robust plan should include time charts, cost, phases, communications howto, dependencies, etc. So I think everything needs a plan, the contents of the plan is what changes depending on the project complexity.
Dwight Eisenhower on planning:
In preparing for battle I have always
found that plans are useless, but
planning is indispensable.
It seems the same in many software projects: you'll find that your plans need to be continually updated and that your first plan was quite different from what you finally completed. But that's okay, it's much better to put some planning in up front than to try something by the seat of your pants.
Agilists try to accommodate such changes in plans by breaking longer term plans into small "sprints" of 2-4 weeks. They'll have more details on the near term sprints, and fewer details on the longer term goals.
You'll especially want to be more detailed and precise if the project is bigger, if you are doing this for an external customer, or if you're attempting something new for you. It's less important (though not unimportant) for smaller projects and types of work you've done before and are very familiar with.
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 posted this question on Reddit Programming and did not get a single response. So I am hoping that Stack Overflow community will have an opinion.
Have any of you ever been on a software project that had fallen behind, where 'Crashing' or 'Fast-Tracking' the project schedule actually brought the project schedule back on track? I have never seen either of these project management techniques actually work. And all the articles on software development that I have read all state that these 2 techniques do not work and actually pushing the project further behind (for example literature on the Mythical Man Month). So who has seen it work?
Thanks Bill.
I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
I've seen it work but it's not the norm.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
study the variance,
study lead and lags;
decide what suits to your project: ‘Crashing’ or ‘Fast-Tracking’.
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
This is a software management questions. If i asked to measure a software project task for my every task assigned to me, means how can i do that? Would it be in percentage (or) out of 10 (or) in man hours?
Any suggestions please?
thanks.
I prefer the done/not-done approach. Either a task that is assigned to me is "done", meaning it's been implemented and tested, or it's "not done". If I'm asked how long I've been working on it, I do track man-hours, but it's not a measure of completeness at all.
Another approach that some people use is "in progress", "implemented", or "complete". "In progress" means that they are currently designing and/or implementing a solution, "implemented" means they are done with code and testing (or waiting on QA to validate the fix) and "complete" means it's all coded and tested.
The problem with percentages is the 80/20 rule. The first 80% of the work will take 20% of the time. The other 20% will take 80% of the time. If you have been working on something for 9 hours and are "90% done" implementing functionality, it doesn't mean you'll be 100% done in 1 hour.
If you are working on something (or have been assigned something), and someone asks how long it will take to finish, give your best estimate in hours, days, weeks...whatever. However, don't estimate too soon - take a look at the problem and requirements and never give an off-the-cuff estimate - it'll (almost) always be wrong. When you estimate, look at similar problems that you have solved in the past and use how long it took you to solve them as a guideline or basis for your estimate.
This idea comes from proxy-based estimating, which is part of the Personal Software Process. It's suitable if you are working on a task on your own. I'm not sure how well it will scale for a team.
What do you mean?
If you mean "My boss wants me to estimate how each task will take me." Then that should probably be done in hours.
If you mean something else, you'll have to clarify.
If you are talking about finished tasks, what you're probably being asked for is for the time (probably in hours) dedicated to each one of the tasks.
How do you know that? You should use some timetracking tool, so at the end of the project (or in any moment) you can know how much time you have dedicated to any of the tasks (and/or breaks, meetings...). If you haven't registered your times, you'll have to make up them, and pray :)
If the project is finished, and he needs to know how many hours were spent on a project to bill it to a customer or something, then you should be keeping very accurate track, maybe using a tool or something.
But he might be referring to how effective the task is. For Example, if he asked you to reduce the load on the foozit, then you should measure the load on the foozit before and after your fixes.
But I think what you're asking is "How do we measure tasks in software development?" And the only sensible way to measure a task is hours. Some people like to measure how many lines of code that have been written, how many bugs were found, or how many tests they've written, but in my opinion, those aren't things that should really be measured for most projects.
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
Some developers when given a task go straight into the IDE and start coding with very little design. They may have an idea of where the application is going as they are coding. I am 1 of these developers. I do this because I feel that if I spend a lot of time designing my application delivery time will be much higher as compared to if I just sit and code away the ideas in my head. My question is that how does application design effect the delivery time of the project and does it have a big advantage over coding the agile way?
Give you a example, when you want travel,
If your destination is near or in your town, you can start right away.
When you want travel to another country, you need package your self first.
Design is for preparation, without it , you cannot go too far(or go the wrong way).
It is not a black and white situation: for some projects it is much better to jump in and start coding, for some it's better to have an extensive planning stage, and for others it is not clear cut.
If the project is small and simple enough that only a single developer is working on it, and how to build it is obvious enough that they can imagine every aspect of it in their head, then they can very well jump in and start designing.
The need for more extensive planning comes about when you have multiple developers, or when the project is large and complicated enough that a developer cannot know everything possible about how it will work from the outset, because it is too complicated to know all aspects of it in your head.
What you describe only works well if you are writing something well well understood and contained. If it is similar to other software you've written you don't need a new design because you can just re-use the old one. however, if it is something totally new, designing on the fly will get expensive. You'll find yourself rewriting too much of the code or worse, stuck with a poor architecture which slows you down. Likewise, if you need your code to be extensible, planning ahead is necessary. If you need it to work with components from other people, planning ahead is necessary.
This approach only really works well if you are working on your own. If you have to work within a team of people, it is important to have a good plan so that everyone else knows what you think is the end goal. This doesn't reduce creativity it just allows you to make sure everyone is on the same page, and it reduces the opportunities for confusion.
(source: yang.id.au)
Just to add a line of thought to your equation scenario, let me contribute this little bit hereafter: I work in a business called YES INTERNATIONAL CORPORATION (www.yesintl.com.au) Sometimes, it does happen that developers may have developed something before so in that case the design is already in the mind. For example, I have developed database solutions in the past which makes us a very fast delivering corporation compared to our competition when I sit down and start developing a project. More experience will make you super perfect as the time goes by... I hope this helps... Andy