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
Background: On a new project I've found myself 3 levels removed from my actual source of information. I report to my PM, who reports to our contractor, who reports to the actual client. Getting answers to questions has become something of a problem and I'm curious to know what people recommend.
Needs: I'm trying to find a technology or disciplined strategy that will assist me in ensuring that the questions I'm asking are getting answered:
Correctly without much modification of the original question
Quickly so the original context isn't lost
Completely so that if a question is deferred I don't forget about it.
Does anyone know of a software suite that assists in this matter or do you have any personal discipline strategies that worked for you?
Thank you for the guidance
One strategy might be to cut out the middleman. Go directly to the client and ask what s/he wants.
On a slightly less bold note, request that you, your PM, the contractor, and the client all meet at the same time rather than on relying on an email chain or technology (which will undoubtedly not serve everyone's needs) to relay information. This strategy works particularly well in my experience, as long as you have a manager willing to let you tag along.
Best technology I can suggest is the telephone. You've got to open up direct lines of communication. But I guess you know that and are finding it difficult, someone along the line is not helping. So now you have to tackle that person, find out why not, what their reservations are and how you might allay their fears.
As for software, I recommend that you DO NOT look for a software solution to this sort of problem. Suppose you implement a new trouble-ticketing system for capturing client questions and comments and to feed back your questions and comments to your client. Next time you tackle your management about the issue one of 2 things will happen:
-- The response will be 'But you told us installing system TT would fix this !'
OR
-- There must be something wrong with system TT, we'll divert our energy to fixing the software.
Oh, and do write things down, so email might be even better than the telephone.
Regards
Mark
I'm sorry, but this doesn't sound like a technological issue. Good project managers ensure communication and should allow you to work directly with the client where necessary. This is a communicaiton/management problem.
PRINCE2 (the project management methodology) would define your questions as project issues (essentially an issue is anything which needs attention so a question is no different to a software defect).
Based on this I'd recommend tracking them the same way you track any other issue.
In your defect tracking system (you do have one right?) set up a category / classification / whatever "Question" and log them and assign them to either the client (ideally they should be given direct access) or to the Project Manager (who now has a way of tracking them and recording the answers).
As with all issues you should make sure you put in plenty of information and context to ensure you get a good answer (obligatory Jeff / Joel reference: in this case to Jeff's belief that you only get out of a question what you put into it). This will also obviously help if you're not the person actually asking it, though as many people have said do everything you can to get closer to the client.
The key point to remember is that people are lazy.
If you formulate questions through e-mail clearly and in format your contact likes, most likely he'll forward them to the next chain of command unchanged and so on.
Some quick tips on how to structure such an e-mail:
Numerate all your questions. Essential, otherwise all too often only the latest question will been answered
Be very specific in what the actual question you need input on is
If there is a fixed set of alternatives or if you have a clear recommendation, make sure this is clearly stated
Avoid mixing FYI messages with the questions. Instead, send separate e-mails
Carefully read your e-mail before you send and look for content that may be misunderstood
Good luck
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 3 years ago.
Improve this question
I just installed trac for this project I'm working on, since it's turned out to be a bit bigger than I anticipated. I've added a bunch of tickets with my clients requests which come in the form of emails, phone calls, and meetings. I've also added some stuff I know needs to be done/fixed but they haven't specifically requested. Should I grant them access to trac so they can submit the tickets themselves so I don't have to keep translating (words into tickets) for them? They're very non-technical, so I'm not sure how well it would work; they might open tickets and not provide enough detail, or get confused by all the different fields.
If your answer is "no", should I at least let them view the tickets, so they can see what I'm working on, what's been done, hasn't been done?
My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.
However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.
So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.
I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.
#Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.
At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.
Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.
Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).
I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.
When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).
Anyway, if you're just using email now, it's not like it can get worse ;)
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
You are working with someone in one project and this someone writes bad code. Not that bad to fire him ar you can`t work with it,
but
person do not follow coding conventions
code is not always covered with unit tests (and it should be)
code is sloppy and do not have comments where it should have them
person do not know design patterns well/do not know at all
put his clothes on your table just as he needs some space.
So how to tell one he need to upgrade his skills, without hurting him? I described something that is a problem. But imagine everything is just fine, except some things that really hurt the project. What to do so that you are still friends, but guy really understood he need to change something?
This is a good candidate for having the entire company do code reviews for a month. You won't single him out (which is good, unless all else fails), and you're better engineers can help him along.
Just stay professional, and point out the problems in your bug tracking, code reviews, or whatever means you have for tracking work items and bugs.
It's the responsibility of the person's manager and the project's PM to determine who is responsible, and to inform the person politely. That is their job, and if they are unable to do this, your project (and probably company) is likely not a very good one to work for.
I would recommend "failing" any code that does not meet the quality criteria. For example, if there are missing unit tests, "fail" the code so that it goes back to the developer to be rectified. This would be similar to having the code fail UAT or something, except it's more of an internal review from team leaders in the development team.
As an example, in one place I worked, I was leading a team of developers. We had PHP production code that was writing unnecessary warnings to the log files, which eventually caused disk space problems and difficulties in debugging the real bugs.
So, to rectify the problem, I laid down the rule: if any code that you've written writes warnings to the log file, the release will fail testing, and you'll need to fix it before it goes any further.
We had almost no warnings being logged on the next release. Now, it wasn't technically a bug, just a code quality issue. The point is that someone needs to be the gatekeeper that reviews and enforces quality controls at some point in the development lifecycle.
Even better, write some automated integration tests that check unit tests exist and code is styled correctly. There are some tools that can check this for you (not sure of the names of them, someone else may be able to enlighten us on that). That way, the build fails an automated, reproducible test. Code would get cleaned up quick smart if that was happening I would say.
You can implement code analysis/styling tools into your build process that enforce certain design and style guidelines. The benefit of this approach is it doesn't single anyone out and it applies to everyone.
Depending on the language your project is using, there are probably tools out there to do this for you. Ex. StyleCop and FxCop for C# projects.
Relax, just invite him for a drink go out and get stoned then explain him the whole situation. The next morning if hopefuly he can still remember, he's gonna understand. If not
this time he's gonna take off all his clothes and put them on your damned table :)
Anonymously leave some books on his desk, like "Code Complete" or "Refactoring".
Assuming you're not his lead, inform his lead of your concerns and let that individual take responsibility for the problem.
write some unit tests that covers his code. He may not know how to write good tests, so he can use yours as an example. Set up automated scripts that regularly run these tests, and send out mail detailing what failed, so that he cannot simply ignore the presence of these tests.
We had a guy at work who only bathed once a week (and no, he wasn't French). And towards the end of the week his BO got pretty bad. We left a bunch of hygiene products on his desk for him to try and give him a clue. Didn't work. I think he started going 2 weeks between baths after that. Phew. This was 20+ years ago.
Coding conventions? Like what? Where to put curly braces?
Missing/bad comments? Well, sometimes no comments are better than gratuitous or wrong ones.
Sloppy code? Maybe so. Post an example or two. Maybe he's a good coder, and you're not that bright. After all, PM's aren't usually that bright, they just know how to kiss ass better than some of us care to.
Design patterns? Bullshit bingo fodder.
But taking his clothes off and leaving them on your desk is strange. IMHO.
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
I have received a request of buying the source code of a website I have developed and I wondered if anybody have been in the same situation and if there is anything I should specially be aware of. Anybody got some advise on how I should handle this situation?
First - a caveat - I'm not a lawer. Not at all. But I care alot about intellectual property and not getting sued, so I try to learn about it a bit.
In no particular order:
Double check your employment rules - when you took the job currently paying you money, what is your arrangment? Did you have to sign any statements giving your company control over all the code you produced? Even if it was a personal, unpaid project - corporate ownership can get you if you signed a strict intellectual property agreement.
Used open source? - there are a few main open source licenses, read through and check them to see the terms for sale of a product with dependancies on open source.
What deliverables does buyer expect? - Built code? source code? Also - what can you do to protect your code (obfuscation).
Do they expect support? - be careful, in my experience with corporate customers, a helpful, free of charge "sure, just call me if you have a quick question" can quickly become time consuming. If you are willing to throw in a free couple hours, be very clear that you will give up to X hours of support for free. And be clear about what your billing rate is after. If you really don't want to support it, make the cost of your time very high.
What sort of support do they want? - answers & configuration help? Bug fixes?
What sort of installation instructions are expected?
What do they own when they buy this? - a single installation for a single server? a site-wide license to install it wherever they wish? or --- worst case -- do they own this lock, stock and barrel such that you may no longer develop it and continue to use it yourself?
Get these answers cleared up, in writing, with signatures.
It's a good idea to have someone external read it to check for ambiguity.
It's an even better idea to draw up the agreement and have a lawyer read it - your lawyer, not the buyer's lawyer.
Avoid any nod/wink/handshake deals. Personal trust is great, but people change if the situation becomes stressful. Or people come and go within companies - the buyer today may be a different person tomorrow.
The first thing you need to consider is:
What license are you providing the code under?
If you don't stipulate a license, they're pretty much free to do with it what they want. Is that what you want? It's hard to answer the question without knowing the specifics of the situation: why are you selling the source code?
If this is a customer and so it's they can do their own custom modifications that you were otherwise being paid to do, the price should reflect that "lost work". Also, you will want to limit their ability to redistribute or resell that source code.
If someone just likes your site and wants the code, be very wary because there's every chance they'll just take it and set up their own. This may or may not be an issue for you. But again consider the issues of resale, redistribution, usage rights and ownership.
Depending on what the code is for, you may also want to consider what it is used for, what it can be used for and how that will affect you professionally or otherwise. It's possibly you may want to restrict the code from being used for certain things (eg adult or poker sites) or you want to require attribution.
Also for all of these things, you need to consider what terms transfer in the event of redistribution (ie how "viral" your license is).
There are lots of open source licenses out there (GPL, Apache, MIT, BSD, MPL, LGPL, etc). I'd suggest you take one as a basis and modify it to suit your tastes. You're far less likely to get in trouble that way than you are with coming up with your own terms.
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.