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 9 years ago.
Improve this question
I work at a software company where most of the people are afraid to install new tools to increase productivity. They give me excuses like:
I don't need to install something else.
I can do this myself.
etc...many other baseless arguments.
In an ecommerece business, the end-users should not have to install anything, everything should be managed by them from the web, and the developers should be the ones installing things to increase productivity and teamwork i.e.:
Version Control Systems
Build Tools (ANT, NANT, Maven, continuous integration, CSS Frameworks)
Integrated Development Environments
Frameworks (Unit testing, etc)
Etc...
How else can I get my point across without sound crass?
Your point of persuasion depends on your position in the company. If you're the newly installed manager of the programming team, get your budget approved and start implementing.
If you're a team lead, then start by picking whatever's most painful and asking for the resources to resolve for at least your team. 2 or 3 months in, show your boss tangible improvements, let them buy in from that perspective and push down to the other teams. Rinse, repeat with next pain point. It may take you a year or more, but just like with iterative development, so must changes to environment (esp. when you're not in direct charge) must be iterative and just practicing what you preach is most powerful influential force when you excel while the others flounder.
If you're not on version control, that's the most critical to get implemented the soonest.
The order I typically implement is:
version control (git, subversion)
bug tracking (trac)
morning scrum meetings
new feature tracking, documenting, and estimating tools (pivotal tracking, mingle)
testing frameworks
continuous builds
I would position every tool in terms of how much time/money/... does the tool save. What does it mean to use it and what does it mean not to use it.
Emphasise the negative impact on their work if not using the tools.
When you're trying to convince management of something, give advantages AND disadvantages. Try to stay objective, and give figures where possible. This will help you convince management (and indeed yourself). It gives management (and your team) confidence if they know you've actually thought something through.
For instance, I worked at a place, and we were looking at improving the speed of the ANT build. It was 8 minutes. I changed it a bit, and it was 3 minutes afterwards. Was it worth it?
We had 8 developers. Lets say they do 3 builds a day.
That is 8 developers * 3 builds per day * 200 days a year = 24000 minutes = about 50 man days.
That is, for a team of 8, if you save them 15 minutes a day, you'll get an extra two man months work from the team each year.
This not only helps you convince people/managers of the worth of what you're doing, but also helps you convince yourself.
P.S. About 6 months previously, we didn't have ANT, and the build was a series of 12 .bat files which had to be run in order. It tooks about 2 hours to correctly build. THAT change was easier to sell to the management.
My two pence of advice - if you need to persuade anyone in management or business for use of something new or different, you need to tell them that it result in increased income (due to the benefits like productivity gains or hours of business manual effort saved etc).
But certainly, in today's environment its really sad to hear that the working population or devs in your organisation are not enthusiastic to try and use new tools/tech. You should also try putting your case with your head of technology - I am sure they will take it seriously.
I'll play the devil's advocate for a minute, and say that sometimes, installing the latest shiniest tool probably isn't the best solution.
Eg:
when you're just about to release a product, and can't afford to spend time fixing your configuration if something breaks, or just learning to make it work the way it used to.
when you know your IDE really well, you've configured it perfectly, and it's still doing everything you need. (I'm thinking of die-hard vi and emacs users here)
when you see your collegues spending more time managing/upgrading/fixing their tools then actually producing results
when the tools are immature/unstable/unsupported
...
That said, there's no excuse for not using version control.
A key point is how well can you rationalize away someone's excuse? If someone says they don't need it, that is correct. However, there may be benefits gained from using the tool but there also has to be guidance, understanding and someone prepared to endure the pain of learning to use the tool. This is where I'd suggest understanding that someone may be afraid of wanting to try something new or not see the benefits from it. Is it so hard to see that someone else may have feelings that are driving what they are saying?
While you may see the argument as baseless, try to see things from their perspective. If they have never done unit tests before, how are they supposed to know why they are good? Same can apply to build tools and other areas of things that others may view as basic if they have had them for years and years.
Seems to me as if you had a lot of Morts in your company. A very sad situation.
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 recently started a career in software development after graduating a couple of years ago in CS. The current project I'm on is a large ongoing project that has it's origins in the 90s with a mix of C, C++, and Java. There are multiple platforms (UNIX, WIN, etc) being supported, older technologies in use like CVS, and some dated documentation in some areas.
The extent of my software development skills stem from going to university as I've had little real world experience. I felt like I had a decent foundation in CS but I cannot but help feel slightly overwhelmed by it all. I'm excited to be part of something so huge but at the same time I feel like it's a lot of information to absorb.
My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.
I've tried poking around the source code and examining how everything gets built but it's on a scale I've never seen before.
How do more experienced people situate themselves when joining a large ongoing project? What are some common tasks you do when getting yourself up to speed?
Good question. I haven't had your exact experience, but in cases like this I like to think, "how do you eat a whale?" The answer is (predictably) "one bite at a time." Reasonable people won't expect you to grasp the whole thing immediately, but they will want to see progress. Perhaps there are some small areas of the larger project that are not too complex, without too many dependencies. Work toward understanding one of those and you're one 'bite' (and/or 'byte') closer to expertise on the whole project.
Being familiar with all existing documentation I would try to get the big picture. Literally.
generate a TreeMap of the source code
I would use GrandPerspective on Mac or WinDirStat on Windows. It will give you some insights about the structure of the project's files (sometimes it gives some hints about the code structure). Having this, you can ask your colleagues for some of the clusters, what they do, how they relate to each other.
learn how to build the project
This is important to have it compiling all the time if you are about to do any changes. Having tests executed at the build time is always a good thing, so ask for it also. Even better if there is some kind of continuous integration server in place. If there is, look at its configuration - figure out how the build is done. If there was no CI server, but you already got the knowledge how to build the project, create such a server on your local machine, and show it to your fellows - they should fell in love with it.
browse the source code with Structure101 or similar tool
This is useful especially for Java projects. This tool does great job. That will give you more details about the code structure, and sometimes about the system architecture. This experience may be sometimes hard, you may learn from this tool that a code is basically a Big Ball of Mud ;)
look for tests, and explore them
If you will be lucky there may be some JUnit, or CPPUnit tests. This is always good to try to understand what those tests are doing. It may be a good starting point to explore the code further.
My coworkers have been great people
and answer a lot of questions I. My
employer hired me knowing that I am
entry level.
You have little to worry about, you're employer knows what you are capable of and your co-workers seem eager to help you out - to be honest most developers love explaining things to others...
From what I've seen, it take truly 6+ years to become fully knowledgeable in a language, so don't expect to become a guru within a year... and even these so called gurus end up learning something new about their language everyday.
Learning a new system (large) will always take time.... the systems were usually not built in 2 weeks but over many years, so don't expect to understand it fully yet. You'll eventually discover what each part does piece by piece.
I know how you feel, because I felt like that once...
"I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia." (Woody Allen)
I agree on what the others said before me. You need some tools that give you an overview on the code. I personally used inFusion (http://www.intooitus.com/inFusion) because it gives also other interesting data beside structure.
The method that has worked best for me is to grab a copy from source control, with the intention of throwing this version away...
Then try and refactor the code. It is even better if you can refactor the code that you know you will be working on at a later stage.
The reason this is effective is because:
refactoring gives you a goal for you to aim towards. Whereas "playing" an "breaking" the code is great - it is unfocused.
To refactor code you really have to understand the code.
Refactored code leaves code that has less concepts to retain in memory. If you don't understand a large codebase its not because you are a graduate - its because nobody can retain more than 7 (give or take a few) concepts at a time.
If you follow correct refactoring guidelines it means you will be writing tests. Although, make sure that you will be working on the modules that you are testing as writing tests can be very time consumning (although very rewarding)
Do invest in buying this book at some point:
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672
But these links should get you started:
Signs that your code needs refactoring and what refacoring to use (From Refactoring - Martin Fowler)
http://industriallogic.com/papers/smellstorefactorings.pdf
A taxonomy of code smells:
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
Good luck!!!
I agree to the first comment but I also Think that you have to learn and see the big picture in some way. You have to trace the main flow from code at least.
I was in the exact same situation several years ago when I joined a software project with 50+ ClearCase version control vobs, 5 million lines of code, and some of it dating back to the 1980's.
The first thing I did was look through every source controlled directory and made a quick summary of my best guess about what the software in that folder did and what language the code was. You can make a pretty good guess by looking at filenames and any comments or documents in those folders.
I then looked at the build scripts to see if they were readable enough to get an idea of dependencies between different parts of the code.
Finally - and I believe this was the most valuable - throw an IDE like Eclipse or NetBeans on top of the code and start reading through pieces of it. Having the ability to jump to the definition of any functions or classes using the IDE allows you to move around a massive software baseline with relative ease.
Overall, have some confidence - it is unlikely that anyone else on the project knows all of the code, so you don't need to either. Use what other people said to get a good idea of the overall project and interfaces and requirements (if they exist) and poke through the code to get an idea of the most commonly used classes and methods.
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 9 years ago.
Improve this question
I have a few software developers working for my projects and I would like to provide them a way to register time they spent on real development.
There is good will to register development hours, no force, but we try to avoid techniques like excel sheets register because this is so uncomfortable.
I can track svn commits, but this is unreliable. Developers also helps supporting different projects during the day, so assuming they work on one project by whole day is not true.
I've seen utilities that popups a message every hour to confirm the project you're working on but this is annoying.
Some kind of active-window-title-anaylzer might help (you can get solution name from there in the case of Visual Studio) but I have no experience with such idea.
If you have any experience with programmers/designers work hours registration, please share with me.
Thanks
Its a good question, and the very best way you can measure hours spent on a development project is not to measure hours spent at all.
You say there is good will to register hours, but I have my doubts. Realistically, from a developers point of view, excessive time management is a distraction for most (perhaps ALL developers on the planet).
I can understand why time is measured so excessively on ODesk. There is a good reason for this, because project time is paid up front by the client to ODesk, and the developer needs to prove to ODesk hours worked. Payment is also guaranteed, and its unlikely oDesk providers and developers ever meet in real life, so there is no trust.
Since its unlikely you're paying your developers upfront, and its more likely you have better trust established, you need to perhaps switch your attention from a management strategy that's cludgy and annoying, to something way more useful.
Yes ladies and gentleman I am talking about Scrum. Throw any notion of keeping hour per hour tabs of your developers out the window (they'll love you for it). And instead introduce Scrum Management into the scenario.
Create some sprints (milestones) for your product development, and in that have a list of iterations (batched deliverable s), try keep your iterations down to a weekly period.
Create a product backlog, and make sure you're aware who exactly is working on what. Find someone on the team to act as a scrum master on your behalf, or to take on this responsibility yourself. Make sure you have daily feedback meetings, keep them short and focused, to identify any risks that might get in the way of deliverable s. Let the developers more or less drive the timing process, and get realistic estimates for tasks.
Read a book or 2 on scrum, and get others and team members involved in the learning curve. Tweak the base scrum methodology to best suit your particular style of management, and I assure you, you will have a very happy team.
Measure your time in man days, and try avoid getting on the back of a developer for hour by hour progress...
There're various time tracking software tools as you have probably already seen from doing google searches. But in all honestly you are asking for the Holy Grail of time tracking. For example do you consider a developer staring at her code and thinking as development time? She might stare at the screen for 1 hour and only type for 10 minutes. In this case it looks like they don't work much when really they worked for 1 hour and 10 minutes. I don't mean to say what you asking for isn't a valid thing to want it just seems to be one of those problems that doesn't have a perfect solution.
Good luck.
I think you're asking the wrong question and are headed for a slippery slope. There's so much that goes into development that has nothing to do with actually coding.
I think a better solution if you're deadset on tracking something is to track the time spent on activities NOT related to development. Of course there's some grey area there too. For example, a meeting to discuss user requirements should probably be counted towards development even though no coding will get done.
you need something like this dashboard to measure time on task. The only way to know the real software developer time is to have then track it. That way when they switch tasks they stop the clock so to speak. I think the hardest thing would be getting the developers to use it as a measure of how long they work on a certain project or even code module, etc. If you can then use those metrics to reduce distractions and other time sucks, you might at least be able to get a decent swag about how much time they spend coding versus email versus talking to other developers, etc.
If you're trying to measure what the developer has as their active window, you have to assume goodwill, because any decent developer can sneak around that if you're trying to turn the screws on them. I spend about a third of my "development time" in Firefox looking at references, for example.
Maybe ask the developers just to keep a log, so you know where their time is going? Whereas that's not ideal, you're never going to do much better than that.
If you are trying to measure the time spent on distractions and disturbances and other task, would it not be in your developers interest to give you this information willingly?
You said somewhere that you are implementing scrum.
If you really have to either take it up at the daily scrum, making it a part of the ritual, or add a very short daily meeting at the end of the day. Let the developers guesstimate how much of the day was spent on distractions and disturbances and other tasks. To me that feels like it will be as close to "correct" as any other way of measuring, considering the difficulties involved.
So, instead of having the developers note down the time, make it the scrummaster's job to sum it up, and make this as painless as possible for the devs. Make sure that the developers gain something tangible from doing it as well, otherwise it is going to end up on the impediment list awfully quickly.
As Dean J implied, you have to trust the developers anyway.
it depends on your IDE - if you are using Eclipse then I recommend using Mylyn plugin. You can measure the time spent on each task. Tasks can be fetched from every famous task repositories i.e. Tuleap. details here
User only need to put the task in Active mode - and deactivate when task is finished to able to stop the timer. I think Mylyn will support such process - if a status of a task changes then this would trigger the active mode (if closed then deactivate the task)
Sometimes development involve using a browser, or a terminal. Eclipse can be used as a browser and as a terminal as well - so developer does not need to leave Eclipse - so almost every activity can be measured related to a task.
Try DotProject or XPlanner
An active window analyzer won't give you reliable results, because your developers will swap between programs (Outlook, File Explorer, version control, internet browser, etc.). Your proposed analyzer won't log that time, although it will very likely be part of the development time that the developer puts into the project (software development is not just coding in VS all the time).
Trying to measure a developer's work hours is the wrong notion. A proper question to ask is what is a programmer's effectiveness. That can't be measured by coding time, time spent sitting in front of a computer, or the like.
As Joel Spolsky put it well in a blog on software craftsmanship, software development "...is not a manufacturing process."
A related but somewhat different discussion appears in this SO article on an invasive programmer productivity measurement tool.
I definitely would not recommend you to use any time measuring software where the developer is forced. It is a massive distraction to developers' concentration.
Instead, the following simple techniques can be used:
Spreadsheet: For smaller projects or team of developers
There's probably nothing easier than to create and share a spreadsheet online, add project tasks to it, assign tasks to a developer, let the developers estimate hours for theirs tasks, let them update their task status(es) (very rough value between 0% and 100%) as they want, let them specify time (hours) it really took to complete the task.
So in the spreadsheet you may have columns:
task name, assigned to, estimated hours, real hours, done (%)
Google Drive spreadsheet may be the answer.
This is a very simple and fast method which distracts developer(s) minimally.
Scrum: For medium to large projects or team of developers
Tasks and the Scrum information are recorded and kept on a board in the office and/or a special Scrum application can be used. A good web Scrum application is Pivotal Tracker which I would recommend for any size of project or team.
More about Scrum:
http://en.wikipedia.org/wiki/Scrum_(development)
In both cases, the product owners (clients or those who deal with clients), project managers and all developers can better and faster:
communicate
estimate
see progress of the team and all individuals involved
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 was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.
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 8 years ago.
Improve this question
We have a project coming up where the PM is insistent that the team should "eat their own dog food"?
At what point is it realistic to do this?
e.g. assume we have to write an editor. We can't use this editor at the beginning to actually code because it doesn't exist. We have to use another editor.
For a while during the project, using a buggy editor is going to slow the project down and will be counter productive.
So at what point do we switch?
Update: After some discussion within the team, the points we will stress during development are:
Implement smallest subset possible to start off with
Identify critical features asap
Only switch some of the developers to use the new product to minimise risk
Some of you should be using it as soon as you possibly can. The first version should be stripped-down, with only the most essential features that you need in order to use it as an (in this case) editor. Once you start using it you'll find out in a hurry which features are important.
<rant>
don't produce dog food, then you don't have to eat dog food.
what is the origin of this sick and stupid phrase anyway? dogs don't produce their own food (with one vulgar exception)...
</rant>
ask the PM what is more important: using the product under development to do development, or producing quality code on time? if there's a conflict, which is more important?
the common-sense answer is: use the thing you are building when it is better than the tools you have.
You don't have to switch to using the development editor exclusively. Start using it until it impacts your production, make a list of the things that are problematic, fix them, repeat until you are able to productively use it most/all of the time.
For a while during the project, using
a buggy editor is going to slow the
project down and will be counter
productive.
Sounds like you have your answer. The time to switch is when your project isn't going to impede on productivity.
This is one of those "it depends" questions. Some guidance:
What are the risks of using the project before it's fully baked? Are they acceptable?
Will the project progress faster or slower, and is this an issue?
Will the quality of the end product improve from a business point of view?
Will you end up with features that make the programmers more productive but aren't useful to the customers?
Conversely, will critical features be deferred because the developers aren't "interested" in them?
Will the "taste of the dog food" motivate your developers?
Perhaps the most helpful guide is what I call "Headrick's Rule," after the coworker who first explained it to me:
If you need someone to accomplish something, make it painful for him not to accomplish it!
The flip side, of course, is to make it pleasurable to get the project done as quickly and as well as possible. Personally, I enjoy building and using tools, so I'd serve the dog food as quickly as prudence permits. But my coworker was a sadist and would have answered, "as soon as it compiles!"
Good luck with your project!
Depending on how the development in being done you can switch earlier or later. If you are using a TDD methodology or where finding and fixing bugs is higher on the list I would start whenever you have enough features you feel would help your day to day life. This could be really early in the development if you have prioritized your features effectively.
Otherwise I would wait until you get to some of the later stages, pre alpha or pre beta. This means that you are not feeling too much pain early in the development.
As mentioned by other, if you can change your development efforts to try to make the product usable earlier do it! I would recommend to have people start using the product in earnest as early as possible to help evaluate the various features and get your initial users emotionally attached to the product. A developer who cares will often put in that extra effort to make the project just that much better.
It's about finding what your "critical mass" of features are. If it's just a matter of bugs and not features, switch now. Fix your bugs. If you are going to need to do feature development before your tool becomes useful, finish those critical features, and then switch over.
And I sincerely hope you're not writing an editor! ;-)
I guess the correct answer is as soon as you can. Of course using a buggy version is going to slow you down at first but then you will perform the QA as you are developing so in the long run you will save time.
I'll suggest that some of your team switch and not the whole team to prevent a big hold if there's a blocker in the application.
When the dog food becomes appetizing AND as soon as possible. I guess this is another way of saying that you should deliver value early and often. And, by the way, never deliver known buggy software. Fewer features without bugs is better than more features with bugs.
its all about size, scalability and scope. If the product would provide valuable success from the "dog food" approach then ASAP would be the correct answer. The end user experience dictates the end result of using the product.
Don't start using it until it reaches an "Alpha" stage. It should have all primary features complete and no known critical bugs. Then you can start using it.
It's also important to have the target users try it out, not just developers (unless it is a developer tool).
You want to have enough development time left to fit in as many "Wouldn't it be great if it did this?" features as possible.
The question is meaningless when applied to software the development team won't use itself, so the developers should use it as soon as feasible. "Feasible" means that it will work reasonably well, and won't break things too badly.
When developing a text editor, the developers should use it early, since mistakes aren't going to be crucial. When developing a version control system, the developers should use it only once it's been shown to be sound. It was something of a big deal when the Subversion team switched away from their CVS servers.
One idea would be to have earlier and later adopters among the team, as the later adopters are likely to spot things the earlier ones have become blind to.
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 11 years ago.
Improve this question
The CodePlex team has a Slack time policy, and it's worked out very well for them.
Jim Newkirk and myself used it to work on the xUnit.net project.
Jonathan Wanagel used it to work on SvnBridge.
Scott Densmore and myself used it to work on an ObjectBuilder 2.0 prototype.
For others, it was a great time to explore things that were technically not on the schedule, but could eventually end up being of great use to the rest of the team. I'm so convinced of the value of this that if I'm ever running a team again, I'm going to make it part of the team culture.
Have you had a formalized Slack policy on your team? How did it work out?
Edited: I just realized I didn't define Slack. For those who haven't read the book, Slack is what Google's "20% time" is: you're given some slice of your day/week/month/year on which to work on things that are not necessarily directly related to your day-to-day job, but might have an indirect benefit (obviously if you work on stuff that's totally not useful for your job or your company, your manager probably won't think very well of the way you spent the time :-p).
I just want to mention Google's policy on the subject.
20% of the day should be used for private projects and research.
I think it is time for managers to face the fact that most good developers are a bit lazy. If they weren't, we wouldn't have concepts like code reuse.
If this laziness can be focused into a creative force, and the developers can read up on technical issues and experiment with architecture and language features, I am certain that the end result will be better code and a more satisfied developer.
So, if you are a manager: Let your developers slack of now and then. Encourage them to hold small seminars with the team to discuss new ways of doing stuff.
If you are a developer: Read, learn and love your craft. You have one of the best jobs in the world, as long as you are willing to put some time into learning the best ways to do your job.
I am currently a full time freelancer working for a single client. If I want to get a full 40 hours of pay, then every minute I spend coding needs to be accounted for on the approved project plan. Or at least it has to go towards some sort of realistic maintenance task. I guess you could say this is one of the disadvantages of contracting... there's really no room for slack or being idle. You just have to keep going and going on the task at hand. It can be quite draining, but then again I kinda like how it keeps me accountable. And of course the pay is a bit better than usual.
That said, I would love to have slack time available for working on pet projects, but no client would ever agree to pay for that.
Anyway, I just thought I'd point out how this exemplifies some of the big differences between freelancing and full time employment.
I've also never worked anywhere where there was a formal policy but I have always found was to squeeze in a little R&D/tool-building time on the side. Often times I will get productivity gains out of that which will allow me even more 'slack' time.
We have slack time and we try to schedule them between releases. Once a release is out, we ask our developers to spend 60% of the day fixing bugs and then the other 40% for slack time. We have policies on what you can use the slack time for though. Then when a release creeps up again, we ask all the developers to spend all day on implementing features or fixing bugs for that release.
The policy lets the developer use the slack time for training, creating something new that the company could use, or just creating tools within the company to make things easier for ourselves. It has worked well for us. We think it is an awesome benefit.
I've never worked anywhere that had a formalized policy, but practically every manager I've ever had has allowed me to spend some time on things that weren't directly related to the current project or fighting a fire.
I think the key is to talk about the things you'd like to try. Most managers want their teams to do something cool, something extraordinary, so if you can convince them that you might deliver something, you might get the chance. Or they might let you do it just to keep you happy.
Now that I'm a contractor rather than an employee, I don't get paid to do fun stuff, but I generally only work 30-35 hours per week, so I still have time to learn and to play.
We don't have a formal policy in my team - mostly because there is just so much work to do that justifying it would be hard. Which is pretty ironic.
I've started doing some formal things in the guise of "Development Meetings" in order to at least inject the essence of this into the team. An example of this is a development project that is intended to both teach new technologies and produce a cool app at the end of it.
It's early days, we'll see how it goes.