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
Ruby coders: How do you monitor your productivity?
I'm curious to know what you use to keep track of how much you do and how well you do it.
For any programming task, the best way to track productivity is by tracking requirements/features delivered. Every agile methodology puts emphasis on delivering working software [read meeting part of the requirements each sprint]. So indicators such as number of lines etc. is moot [when you have a person pair programming most of the time and checking in code with the other person's login].
As with an language, you must set goals/milestones for your project. You then break those goals down into individuals tasks. The smaller and more specific a task is, the easier it will be to track your progress. I use a project management web application called Redmine to keep track of these tasks. After I have devised the tests, I begin creating the code tests that will outline the code criteria for each test. My primary use of Ruby has been with Ruby on Rails which has excellent support for testing. Once I am done with the tests, I begin coding the application. When the application passes all the tests for a given task, it can be marked as completed.
At the beginning of a project, you can judge by the relevancy and number of tests. Afterward, the number of passing tests.
Relevancy is the key word, of course. If the code doesn't do anything yet, or doesn't deliver any value, then getting it to that point is your number one test of productivity.
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'm working in company with a big system with a messy code structure. I want to work with the right standards like polymorphism and design patterns.
But the code is such a mess and needs to be heavily refactored to do that. Also my current company gives me tasks, and if I have would heavily refactor, that will open many bugs in the system as it's not unit tested, of course.
What do you think? Should I work on the tasks on this bad structure to finish the work? Or tell them that we need rebuild many things (also they won't find a difference as the features already work now).
I think you need to start off with some unit tests.
Whilst doing the tasks you have been assigned, you could write some tests to test the code you are about to change, then you can refactor it.
Now you can start to write the code for your task, test-first.
If the code that is already there works, then refactoring is the best option. If it doesn't work, then a rewrite becomes possible.
Well...you need to work on multiple aspects.
First, learn best practices to write clean code (if you haven't yet) and request your team members the same. There are many useful books and online resources available for the same.
Second, do not expect that the situation will change overnight. Adopt "Boy scout rule" - it will gradually improve the code quality.
Third, start building your corpus of unit tests. Slowly, testable code will emerge out of the sea of untestable monolith.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Scrum is one methodology in agile software development right? What are the main activities in Scrum?
I hope this will help.
Nains...
Scrum is indeed an agile software development methodology.
It's more then a set of activities - there are a set of core assumptions and ideas that underlie the activities. Nains' answer contains a cheat sheet explaining very briefly the important concepts.
To answer your question in the most basic sense.
Gather user stories
Determine priority within these stories, chop them up in small, manageable tasks.
Code-code-code
Every day: short meeting where team members explain their progress, what they're working on, and where they get stuck on.
Every two weeks (or week, or month... depends on your project): deliver a working copy of what you have.
Return to step 1.
One such loop is called a Sprint. The essential step is that you begin by revisiting your assumptions what the software needs to do - the user stories, and their priorities.
Also note that this is a short cycle, within a very short period of time, the users get feedback.
Note that there is a lot more to be said about Scrum - if you want more details, I recommend a good book, or at the very least reading the Wikipedia article.
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
How do you start planning a fairly large project? Do you immediately start writing up the major classes and break it down further and further? Do you sit down and draw out some UML?
I'm designing my first large project (well, large compared to the other ones) and I'm looking for ideas.
I suggest reading about agile methodology and scrum.
Large Projects would be beneficial when used Agile scrum methodology.
Agile methods divides your projects into smaller sprints giving one the time to prioritize the main features to be concentrated & completed.
Continuous interaction with client means less ambiguity, more real value. The client would see live ideas before final. So more improvising at very early stage with ample of time to make it better.
Bug fixing process gets speedy. Less the bugs, more efficient the Project!
By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly and frequently, with a high level of predictability. This also provides the opportunity to release or beta test the software earlier than planned if there is sufficient business value.
Improves Quality. By breaking down the project into manageable units, the project team can focus on high-quality development, testing, and collaboration. Also, by producing frequent builds and conducting testing and reviews during each iteration, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.
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
Someone within my organization has started pushing for us to pilot the CMU SEI's TSP process (see website here). I have an instinctual aversion to any attempts to cure software development illnesses with alphabet soup, but I would like to know if anyone has experience with this process and can provide tangible facts.
I used to be a fan of SEI's CMM. I even read Watts Humphrey's "Managing the Software Process" book cover to cover. I haven't used TSP but I suspect it has similar strenghts and weaknesses as the other software processes.
Definitely read about it and what they claim it can do and how to implement it, but be vigilant about keeping your software process small and flexible. You need one, but be careful about taking processes from someone else.
good luck.
We've been using this process for a few months now and I'm not particularly impressed. This process is only suitable for a strict command and control style of management where programmers are essentially bean counters. Most of the good parts of this process (size estimates rather than time estimates, self reviews, detailed plans, logging time against plans, and keeping a log of defects and errors for later review) can be implemented without throwing a bunch of money at SEI.
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 4 years ago.
Improve this question
As a project manager, you are required to organize time so that the project meets a deadline.
Is there some sort of equations to use for estimating how long the development will take?
let's say the database
time = sql storedprocedures * tables manipulated or something similar
Or are you just stuck having to get the experience to get adequate estimations?
As project manager you have to remember that the best you will ever we be able to do on your own is give your best guess as to how long a given project will take. How accurate you are. depends on your experience and the scope of the project.
The only way I know of to get a reasonably accurate estimate that is it to break the project into individual tasks and get the developer who will be doing the actual work to put an estimate on each task. You can then use an evidence based algorithm that takes the estimation accuracy of each developer into account to give you the probability of hitting a given deadline.
If the probability is too low, you have two choices: remove features or move the deadline.
Further reading:
http://www.joelonsoftware.com/items/2007/10/26.html
http://www.wordyard.com/2007/10/11/evidence-based-scheduling/
http://en.wikipedia.org/wiki/Monte_Carlo_method
There's no set formula out there that I've seen that would really work. Fogbugz has its monte carlo simulator which has somewhat of a concept for this, but really, experience is going to be your best point of reference. Every developer and every project will be different!
There will be such a formula as soon as computers can start generating all code themselves. Until then you are stuck with human developers who all have different levels of skill and development speed.