I'm using Git with git flow (http://danielkummer.github.io/git-flow-cheatsheet/[^]) and i love it ...

gzo

Woaw, working 8 hours ... ... in a row without any intermediate point to see whether the code will work ... and ending the session with a run that you expect to crash and to debug that is really too much for me, now that I'm used to 5 mins cycles with refactoring and TDD I'm not amazed but sorry for you :-(

gzo

Why don't you speak to this colleague ? Until today, to speak is the best way to explain your point, and to be understood. You might even learn something doing so ... To play more stupid than the stupid is a sure way to failure, for both you and him.

gzo

Estimation isn't useful if you cannot decide the priorities of your tasks and if you're working alone. Even worse, if the big planning of your project has been decided up-front, then your estimation has no impact therefore no value. Maybe in this case, you should do it anyway to know whether you're in trouble or not :-) In all other cases, estimation can be a big help to organize work, for you and your team. It's an organizational tool to get information, to help make the right choices and to give responsibility to the developers Estimation is a tool, it is not about predicting the future, but about asking questions and being able to face difficulties more efficiently when they arise. Estimation i talk about here is for small tasks (max 20 hours). That means that bigger tasks have to be slit in parts, so that actual tasks are always less or equal to 20 hours. Obviously, it doesn't apply for a whole project's estimation ; I don't go into that "reassuring" part for the managers. ABOUT PRIORITIES When priorities are not yet fixed, many parameters can influence the choice of the tasks that will be worked on first (and leaving other tasks for later, maybe never) : - the risk involved with the task (some tasks give you information and have big impact on further decisions) - the ideal date for your client (some tasks have more value if they're finished before some date) In these cases, estimations enables you to make informed decisions about priorities, therefore using your resources at their best potential. ABOUT TEAM ORGANIZATION if you work in a team, especially in self-organized team, it is useful to know when tasks will be finished : - it allows organization in merging the work with other people's work - it allows organization of limited resources (machine, expert people, customer's feedback, etc) - it allows to take decision, for instance : to split a task between people because the we'll get more value of the task if it is finished sooner - it allows to have a developer responsible for the task (volunteer) estimation is also useful as a tool to work more effectively as a team : - whether the task is big or small (which in some cases you don't know from the start), estimation forces you to know what is takes to declare the task "done" it is an agreement between the development, the testing / validating part, and the customer. ABOUT PEOPLE it helps to manage people who don't really care about the project's outcome (i have to work with such people, and since i can

Regarding the version control problem with reformating, it could be avoided if only AST (abstract syntax tree) of the program is saved. Then viewing a file becomes rendering the AST with the programmer's local preferences. And compilation, static analysis, etc would become much easier and faster. I guess that will happen one day. Right now, a browser rendering a HTML file does a little bit of this. Or for instance, rendering a XML file with a XSLT file

gzo

After spending some time on similar problems, my position is that "code reuse" is a purely technical matter rather than a business decision. It goes this way : - the specifications have to be expressed first, by the user (or product owner or client or whoever ...) ; he is able to add whatever constraints to the system, as long as they are external to the system (for example, he decides the interfaces of the system) - depending on what is needed, i see if and what available components can be reused ; these components can come from previous projects or from external sources (such as web, ...) - i write down an estimate of the total price, depending on what i know can be reused and what has to be created from scratch - the client is then able to accept my offer ; there is no bargain, and he has nothing to say about the technical decisions about the internals of the system - if he doesn't agree with my proposition, his freedom is to change the needs (or to find someone else to do the job) Any similarity with a big "planning game" would be normal :-) It works better on small increments (because some change will happen soon or later, and a small scope means smaller changes) That way, there is no such thing as "just take this and do that and that ..."

gzo

The stupid thing was not to send it to the customer, but to write stupid code (or stupid messages) Doing this, you just promise yourself that you'll have to come back and clean it :-(

gzo

Train people to follow Covey's advices in his book "The Seven Habits of Highly Effective People" (http://en.wikipedia.org/wiki/The_Seven_Habits_of_Highly_Effective_People[^]) And use Agile / XP values like simplicity, communication, feedback, courage, respect for everyone (not limited to software people) Cheers

gzo