About nine months ago I was hired to create a modern "agile" development shop with an IT department that had a legacy product built on Access, SSRS, stored procedures, an old version of Sql Server, etc...
It broke every single rule of what I look for when accepting a job. I only took the job with the condition that I would have 100% support, budget and time to set things up right from my future manager.
I laid out my vision....
1. Realistic timelines based on a 40 hour work week. All estimates and deadlines were based on realistic hours, realistic staffing levels, and realistic utilization.
2. I would be given the time and budget to setup a proper CI/CD platform.
3. We would put in all of our estimates time for automated testing and code reviews.
4. Devs would have direct access to the (internal) customer.
5. I would have the budget to contract smart people at market rates.
6. Any dissension from the legacy developers with an attitude of "why do we need to change. That's the way we've always done things" wouldn't be tolerated. If they couldn't get on board, I would hire my own team and let the existing developers support the legacy product.
It's working well so far. I would never have accepted the job as just another developer. I only accepted it as an architect that was given the authority to make the changes. I haven't gotten any push back from the higher ups. I had to sell everything as a long term cost savings:
- automated tests keep the cost of hiring QA down. QA only has to test new functionality. The more automated tests you have -- both unit and integration tests - the less manual regression testing you have to do.
- automated testing also allows us to ramp up with contractors and you don't loose business knowledge when people leave because the business logic is in the automated tests - not a bunch of documents in SharePoint. If a contractor comes in and makes a change and the tests break, they've broken a piece of business logic.
- Once everything is setup, and documented, you don't need dedicated "release engineers" all releases are coded with Powershell and configured with Consul. We treat servers like "cattle not pets".
We also based the project on Mongo and not sql server so we don't have to worry about database deployments. We decorate the fields in our POCOs that are being stored with attributes that tell the individual services at startup to auto create any missing indexes that we need. Schemas are enforced by microservices that are the only way to access Mongo.
That right there is one of my biggest pet peeves in any dev shop. It's astounding how few people see the connection between "the way we've always done things" and "the problems we've always had".
See a more detailed summary in my previous response, but well so far. If it doesn't work out, I have no one to blame but myself. I've been giving the authority, the budget, and the support to do it right.
Comments
About nine months ago I was hired to create a modern "agile" development shop with an IT department that had a legacy product built on Access, SSRS, stored procedures, an old version of Sql Server, etc...
It broke every single rule of what I look for when accepting a job. I only took the job with the condition that I would have 100% support, budget and time to set things up right from my future manager.
I laid out my vision....
1. Realistic timelines based on a 40 hour work week. All estimates and deadlines were based on realistic hours, realistic staffing levels, and realistic utilization.
2. I would be given the time and budget to setup a proper CI/CD platform.
3. We would put in all of our estimates time for automated testing and code reviews.
4. Devs would have direct access to the (internal) customer.
5. I would have the budget to contract smart people at market rates.
6. Any dissension from the legacy developers with an attitude of "why do we need to change. That's the way we've always done things" wouldn't be tolerated. If they couldn't get on board, I would hire my own team and let the existing developers support the legacy product.
Did it work? It sounds like you made all of the correct conditions, but that seems like an incredibly difficult environment for you to succeed in.
It's working well so far. I would never have accepted the job as just another developer. I only accepted it as an architect that was given the authority to make the changes. I haven't gotten any push back from the higher ups. I had to sell everything as a long term cost savings:
- automated tests keep the cost of hiring QA down. QA only has to test new functionality. The more automated tests you have -- both unit and integration tests - the less manual regression testing you have to do.
- automated testing also allows us to ramp up with contractors and you don't loose business knowledge when people leave because the business logic is in the automated tests - not a bunch of documents in SharePoint. If a contractor comes in and makes a change and the tests break, they've broken a piece of business logic.
- Once everything is setup, and documented, you don't need dedicated "release engineers" all releases are coded with Powershell and configured with Consul. We treat servers like "cattle not pets".
We also based the project on Mongo and not sql server so we don't have to worry about database deployments. We decorate the fields in our POCOs that are being stored with attributes that tell the individual services at startup to auto create any missing indexes that we need. Schemas are enforced by microservices that are the only way to access Mongo.
That right there is one of my biggest pet peeves in any dev shop. It's astounding how few people see the connection between "the way we've always done things" and "the problems we've always had".
you are leaving out the punchline... how is it going?
See a more detailed summary in my previous response, but well so far. If it doesn't work out, I have no one to blame but myself. I've been giving the authority, the budget, and the support to do it right.