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
What are some good procedures to follow when handing a project to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.
As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.
Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.
I've been on both ends. Taking over a code base and handing it off.
You should:
Identify areas that aren't completely
obvious. So, if you have a directory
called "xml" but all your flash
object get their data from
"flash/swfs/xml" you should document
that.
Identify parts of the database which
are no longer in use. If there are
tables that simply have no use
anymore.
Identify areas of concern such as
speed/performance of certain pages.
If you have some really backwards
logic on certain pages, explain why,
if it's not been commented in the
code directly.
Any third party vendors should be
identified along with their cost and
use on the site. So if you're using
a delivery network to stream your
flash videos, definitely let that be
known.
If you have pages still in the
project, but aren't being used
anymore, identify them, or simply
remove them.
If you know for a fact that your
database was poorly designed,
contains no constraints or indexes
and has no primary keys on many
tables, mention it. It will let the
new developer know they need to
optimize the database.
If you hardcoded e-mail addresses
within the code and didn't put them
in .config files, identify that as
well.
I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.
If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.
But training is always nice.
For anything that requires a build environment (certain compiler, 3rd-party libraries, opensource libraries, paths, etc.,), have the original developer sit down with the new developer, at the new developer's workstation, and walk through the process of making a simple change, committing to the source control, building, smoke test, etc.. Lots of times projects that are out of the mainstream may have odd procedures for testing, or they may come from an unfamiliar repository branch, may need a specific compiler version, libraries, etc.. Bugs may be tracked differently, it may require specific logins or endpoints for testing, etc.. By walking the new dev through the process, on their workstation, you'll uncover all of those issues, saving the new dev lots of frustration.
Related
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 8 years ago.
Improve this question
I'm a relatively new developer (two years experience, coming from an apprenticeship) and in my workplace we've only ever had one developer working on a project at a time.
We keep our projects in Microsoft Visual Source Safe and check out files as required, and checking back in when we're done.
However, I've been doing some thinking lately and I'm unsure how we'd work on the same project at the same time? Almost everything has dependencies on some core code and certain base classes. Is there anywhere I can go to read up on concurrent development, or are there any 'techniques' I should be researching?
How do team work on projects together? For background information I'm a .NET developer working mostly with VB.NET and webforms, but am moving onto C# MVC.
Edit
I think what I'm really asking here is about the techniques that should be employed as opposed to the software. I've been tinkering with Git a little and can see the benefits of the system over VSS. I was looking more for help with techniques on a project level that can be employed with concurrent development;
Should the development of two sections be completed then merged, or should it be more closely worked on together?
Are there any proven techniques or best practices when it comes to reviewing changes or discussing the next move?
Are there any books or articles I can read on how to produce a project as a team more efficiently etc?
Given you are using a Microsoft Stack, does it not make more sense to update yourself and use TFSOnline as an example. Its far better than its predecessor and everything is fully integrated into your toolset (assuming you use Visual Studio). There are loads of tools out there but everything I use is free inside a MSDN subscription and it plays nicely together. I am not saying others aren't ahead of the game but it makes more sense given what you are doing. Was very surprised to see SourceSafe stil being used.
I never used Visual Source Safe, but most chances are a different source control tool called Git (http://git-scm.com/) will make the concurrency better.
As the project will grow, you will probably have less collisions - just because there are more files to work on.
Try to push back the code more often. No more than 1/day - and hopefully sooner.
Use some kind of SCM(source code management) Wiki,
You can use some kind of program to help you, today the most popular program to this is GIT Wiki Git, but have many others. Do some research and find out what is better for you.
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
What steps can one take to mitigate the risk of a one-person team working on a project, especially when that one person is a rather junior programmer?
I ask because I am that junior programmer, and there is no one available/willing to do things like code reviews. Part of the problem, I suppose, is that I am working on web applications in an embedded software company, so most employees' expertise is in a different area.
Recognising this as a problem is more than most "junior programmers" would be able to do :)
Unfortunately most employers don't see the benefits (only the downsides) in multiple people on the same task.
With lack of understanding from your employer on this point, just stick to all the usual rules, such automated testing, documentation, and source control. I know too well that when working alone on a project, it is all too easy to become complacent.
The truth is that the documentation is not just to help others know what your code does. It helps you too. Source control is not just to enable multiple people to work on a project and merge changes, it helps productivity (in the sense that you can easily revert changes), enforces backups, and gives you good tracking of where your time and effort has been spent.
Source control and automated tests are two things that will help in any environment. Those two things alone will mitigate some of the major disasters (lost work, buggy code resulting from constant changes and refactoring).
Beyond that, stick to the basics: K.I.S.S. Keep your code design as simple as possible, keep your classes simple, follow the Single Responsibility Principle and above all, avoid duplication (which will greatly guide your designs). Make use of every resource you have: message boards, other programmers at other companies, friends from school, whatever you have available to you. Even having a mentor you can send e-mail to is helpful.
Best practices aren't much different than for a larger group. Source control, unit testing, follow a style guide for your language, script everything instead of using manual processes, and try to have at least some high level documentation and comments in the tricky parts of code. For specific decisions that are important and hard to change, like how your code interacts with the database, try to find out what approach a well-designed project uses, if necessary by checking on this site.
Unit tests especially are a great way for other people to quickly figure out how your code is supposed to behave, and to check whether their changes have broken anything.
StackOverflow is full of available and willing people to help solve problems and give advice.
Other than that, be prepared to make mistakes and learn from them.
Oh yeah, and get a copy of Code Complete!
As #MattJ mentioned, the fact that you care enough to try to mitigate that risk implies much more seniority than your current job title purports.
I would say that you should do all of the normal things you do to mitigate risk and, where it's not possible to get another resource, just either do it yourself, or skip that step.
It's the best you can do.
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 5 years ago.
Improve this question
I'm looking for a good template on server-side installation of software for a project I'm working on.
The client-side is pretty straight-forward. The server-side installation is a little trickier. It is made up of several pieces (services, database connections, dependencies, ports that need to be unblocked, etc.). During a recent test, several undocumented pieces were discovered. Now I need to create installation documentation for our disaster-recovery plans and ways to test the installation without necessarily having a "full-up" system to test on.
I'd really like a suggestion of where I can get a template or a really good example of such a document. I'd like it to be something that an operator could read and comprehend in the heat of a recovery.
[EDIT]
Our current documentation comes mainly from the questions our administrators have had during off-site tests. As new code is written, I'd like to make sure the documentation is written ahead of time. I've been collecting VMWare images to start testing, but was looking for some good examples. It's a Windows Server shop (2000 & 2003). Word templates would be great, but if I could see good documentation, I could create the templates. Any suggestions about what should be tested would be great as well.
[2nd EDIT]
I've gotten several good ideas from the answers posted. After changing my Google search, I came up with some good starting points. They're not perfect, but they are a good start.
Microsoft Exchange - http://technet.microsoft.com/en-us/library/bb125074(EXCHG.65).aspx
iPhone - http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://www.novell.com/documentation/gwgateways/gw7_exch/index.html?page=/documentation/gwgateways/gw7_exch/data/ab32nt1.html
http://cregan.wordpress.com/2006/06/22/exchange-2003-step-by-step-installation-instructions/
http://technet.microsoft.com/en-us/magazine/cc160942.aspx
Covers planning in the design stage well - http://www.onlamp.com/pub/a/onlamp/2004/04/08/disaster_recovery.html?page=2
[Edit 10/29/2008]
THIS is the type sample I was looking for. It doesn't have a lot of garbage, but seems to explain enough of the why along with the how http://wiki.alfresco.com/wiki/Installing_Labs_3_Nile
The most complete method that we've come up with for creating our DR documentation, involves going through a full cycle (or two) of installation, and documenting each step along the way.
I realize this can be a bit difficult if you don't have a test (or replacement) system to use to create your documentation - but it's worth lobbying for running through this cycle at least once.
(I recommend twice, the second being done by someone not involved with the project - this is how you test the documentation for future admins, who may not be as experienced with the process.)
A side effect of the above is that your documentation grows fairly large - last I had to do it, I believe the completed installation manual for our database servers was 30+ pages.
What should be tested? Well, in the case of a web site, "can you get to the page?" Include a URL as a starting point and let the admin click through to a certain point. It is not necessary for the admin to go through the whole QA cycle, just a confirmation that what you meant to be deployed is really what got deployed.
Other ideas
Also, we (my team at my last job) had QA test the deployment. As a QA person should be, he was not intimate with the details and as he deployed to QA, we were able to get feedback on what went wrong.
Another thing that is useful is sitting down with the admin(s) before the deployment. Go over the instructions and make sure they understand them the same way you do.
Template? Just make sections that have fields for data such as URL to DEV, QA, and PROD. When you write out the instruction you can refer to those. Just make it clear what is being deployed.
Depending on the admins, automation is helpful. I've had windows admins that want a Word doc with step by step instructions and other admins that wanted a script.
However, some helpful things to include, probably as sections
Database changes
Scripts to run
Verification that they worked
Configuration changes
what are the change
where is a version of the new file (In my case they diffed the two, which helped reduced errors concerning production-specific values)
General verification
what should be different from the user perspective (feature changes)
For web farm deployments, it might be helpful to have a coordination document concerning how the servers need to be pulled in and out of pool.
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 10 years ago.
Improve this question
As a contractor, out-sourcer and shareware author,I have about 5-10 projects going on at any one time. Each project has a todo list, requirements need to be communicated to other outsources and employees, status needs to be given to clients, and developer's questions need to be answered.
Sometimes it is too much... but then I realize that I'm not very organized and there has to be a better way.
What is your better way?
How do you keep track of requirements for multiple projects, assign work to multiple developers, obtain and give status for multiple projects to multiple clients?
What tools do you use? What processes?
This may sound really old-tech, but a different set of notepads for each project. Now, hear me out.
I know that notepads aren't searchable, and they aren't indexed, etc. But they will have meeting dates and times (if you've been taking notes during meetings, even on the phone), they have the ability of never crashing, and they're future proof in the event of wondering what you did a few years back but can't remember if the old project files made it to your new hard drive.
But the biggest reason is CYA-- logbooks and notepads can be used in the event of someone suing you as legal documents, especially if you've been diligent about dates. It might also work during patent discussions as well, showing a clear date and time of ideas being made. During another life, I worked in biology labs, and electronic record keeping, because it's so fickle, wasn't allowed for the legal reasons of being able to show that the work you did was your own. That attitude has permeated my own project notetaking, and helping to keep track of everything I need to get done.
You should have a look at No Kahuna Easy to use; Free and Pay versions; active, responsive development team.
tools are not the answer, unless you already have the knowledge, organization, and self-discipline to use them well. i highly recommend Getting Things Done
I'm a big fan of http://trac.edgewall.org/'>trac for managing software projects. It provides task and bug management with integrated wiki and source control.
We have been using FogBugz for managing several projects (10+) and clients (20+) for more than 4 years.
We have a project for each product and another project for each client. In this way I can control the requirements for each product and the pending activities related to each client.
Try Omniplan if you're on a Mac. I find it just makes sense. I also find I don't end up fighting the interface and instead concentrate on using it to help me plan better.
Edit: It goes well with OmniFocus and no, I don't work for the Omni Group :)
If you are into Agile methods (or even if not) you could try some of the Agile tools out there. Look in http://www.agile-tools.net/ for some comparisons. I use xplanner at work where we coordinate requirements and work over iterations among several teams. It has its quirks but it generaly gets the work done and allows for some useful agile structure. I am sure some other will have preferences for more mature tools.
Trac (as Mark Roddy mentioned) is also nice, because it integrates a wiki, task and defect management, so it can be an interesting tool if you have none of those already in place.
I should say that we use Mantis now, but I wish it was better. I wish I could use it for customer-facing queries, I with I could open and assign issues by email.
ScrumWorks Pro looks promising, but amazingly expensive for me, with 15 developers.
AccuNote may be an option, but it is new to me
I'm using the customer support, project planning and issue management portions of OpenERP. Having your issues and feature requests, along with the tasks required to get them done on the same CRM that allows you to manage your customers is a big benefit.
I have used SourceGear Vault to manage all our software projects. Our business nature is very much driven by project basis - typically I have 5 active projects running at one period of time.
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 have MS Sharepoint -- which isn't all bad for managing a task list. The data's publicly available, people are notified of changes and assignments.
I think that Bugzilla might be a little easier for management and reporting purposes. While there are some nice Open Source Scrum management tools, I've used up a lot of my political capital and can't ask for too much more than what we've got now. Money isn't the object -- obviously -- it's the idea that my team has too many specialized tools.
Will Bugzilla work out as a more general project management tool -- outside the bug fix use cases?
Will I be bitterly disappointed and wish I'd downloaded something else and made my case for a better project management tool?
Bugzilla Is a great bug tracking system. We have tried to use it for other project management tasks and the results are less then stellar. I would recommend finding something designed with your goals in mind.
Try it for yourself.
Get a $15/month account at wush.net and use it yourself for a while (no business relationship besides satisfied customer).
Bugzilla is powerful and has a lot of configuration options, which can be confusing.
I personally used it three years ago on a project I was working on. I had no project manager and I was the developer, so I needed a very-light-overhead systtem. Bugzilla gave me that. I put my main goal as an enhancement "productionalized system" and then I made dependencies to reach that point. I ended up having 160 nodes all dependent on each other. This essentially was a work breakdown structure. I didn't bother with time estimates, and I didn't bother with creating any other kind of project documentation.
A cool advantage was that as I coded, if I noticed something needed to be done, I would just pop it into bugzilla (20 second process once it's set up), tie it as a dependency, and go back to what I was doing.
Whenever I completed a task, I would look at the dependency diagram and find the outermost leaves (bugs that blocked other but weren't themselves blocked), and work at it.
The advantage of this method for me is that if a task had looked simple and had one node associated with it, but when doing the thing itself I realized it was more complex, I would just split it into different subtasks. This took only a minute and absolutely didn't involve a meeting with a project manager.
Other people on the team could track my progress by looking at open bugs, closed bugs sorted by dates, etc. They saw action, they left me alone. When I had external dependecies, I would make a bug, detail the work, and send that person a link via email. They could then see why this was needed by looking at the dependency diagram.
Note that unless previously agreed upon, I did not assign them the bug.
It worked really well and the system was ready one month early.
How will it work with SCRUM? Having only had a cursory glance at scrum I can't tell you. But that was my experience.
Using a dedicated host will allow you three things:
support
easy upgrades (unless you got gurus in-house, bugzilla management ain't easy--for me at least)
users across organizational boundaries.
Note that bugzilla has all sorts of security features, so it's easy to lock-down the users to what they need to see.
My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.
We've used Trac and Subversion very successfully for several projects.
The main advantage here is being able to tailor reports, some very Scrum specific, to provide information to management.