

Ask HN: How to Allow Core Team to Work on Innovation Project - atentaten

I&#x27;m in an environment where a new project is being discussed where a couple of members from the Core dev team will be asked to leave the core work and start this project.<p>I feel that it&#x27;s not good to have the other existing core devs to not be part of this new project that will be replacing the system that they will ultimately be maintaining.  Those members are eager and passionate to contribute to innovation and I feel not allowing that is harmful.<p>I recently read this article about how Facebook had their core team working in parallel on an innovative project. 
https:&#x2F;&#x2F;hbr.org&#x2F;2015&#x2F;06&#x2F;an-inside-look-at-facebooks-approach-to-automation-and-human-work<p>I&#x27;m wondering how to do something like this on a tactical level, especially in an agile scrum shop?
======
i0nutzb
Rewriting is (almost) always a bad idea. (and you're planning some kind of a
rewrite, since the new system will replace the old one)

Let's assume that Team A will work on the newer version, while Team B will
continue to work on the old version.

Team A will start working and implementing stuff. Team B will keep working on
the old project and add new features. Team A will need to keep up and add new
features that Team B added, and so on.

> Those members are eager and passionate to contribute ANYONE is eager to
> contribute to a brand-new project!

\--------

How I'd do it?

1) Incremental changes on existing product. Unless you're using some ancient
programming language and you have troubles on finding programmers (or you have
some licensing options, or the product is locked on a certain platform; e.g.
is written in obj.C and you want it ported on Windows and/or Linux), probably
this is the best approach. If the system is too big to add features at first,
start improving existing code. Clean up. Add unit tests. Clean up even more
and start adding features.

2) If you're set on rewriting and this is the only option to consider,
feature-freeze the existing project and move all developers to the new project
(every once in a while, pull a developer to fix critical bugs _only_). Don't
pull the same developer twice in a row though and don't ask them to fix
trivial stuff.

\-------

Additional lecture (in no particular order):

\-
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

\- [http://programmers.stackexchange.com/questions/6268/when-
is-...](http://programmers.stackexchange.com/questions/6268/when-is-a-big-
rewrite-the-answer)

\- [http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-
Alm...](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-
Rewrite-Your-Software.aspx)

\-
[https://www.lessannoyingcrm.com/blog/code_rewrite_cautionary...](https://www.lessannoyingcrm.com/blog/code_rewrite_cautionary_tale)

\- [http://programmers.stackexchange.com/questions/6255/have-
you...](http://programmers.stackexchange.com/questions/6255/have-you-ever-
been-involved-in-a-big-rewrite)

