7 ms·
Personally what's interesting for me is: 1. (Assuming you're an outside contractor) How much do you charge? 2. How do you do estimates on this project? Or do
by raihansaputra 7y ago
Personally what's interesting for me is:
1. (Assuming you're an outside contractor) How much do you charge?
2. How do you do estimates on this project? Or do you just do it bit by bit?
3. Are you switching over part by part or will deploy in a period?
If you can, you should at least write a blog post. A book will be amazing though!
- bpizzi 7y agoI'm a simple employee with some management duties, it's small company (20p), I estimate my wage to be on the low end of the local market (french, not in the capital), but the position is quiet unusual so it's difficult to compare. At the beginning there was only vague goals, not estimates, now 4y later I can tell how much days a functionality will take within a 30% margin error. But it's only based on personal appreciation, tightly coupled to having personally designed the new arch from the start. The migration strategy that I chose was to hijack the sales activity and pick which new projects should go on the new version. That way we can stay away from replacing years of specific functionalities for picky customers until we have a good idea of how much the business module is ready for prime-time. I should definitely write a book, there's so much to say - maybe in 2020! :)
- raihansaputra 7y agoDefinitely quite a unique position compared to the common rewrite story. Small company, long-term rewrite timeline, small rewrite team, able to influence the sales activity and deployment. I think these constraints are important to your success (and fun factor), but I don't have the complete picture. I'm really welcome to any points against what I wrote above; currently I'm intrigued on reading on how software projects works or doesn't work in real life and your story is really interesting.