|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Requiring Technical Debt Payments I was working with a customer recently that is trying to improve their processes. This was a large company, over 100,000 employees, though most of them aren't in the technology area. However, across many divisions and groups, there are a lot of developers and operations personnel who have tended to work in silos, managing their own applications and systems in disparate ways. In other words, doing software development the way most companies do it. I had been working with one group to streamline and standardize some of their software practices to implement more of a DevOps flow to smoothly build, operate, and update their systems. They've had some success and other groups noticed that this set of teams is very efficient. They aren't DevOps like a lot of the articles you read. They still have development and operations, but the groups work closely to ensure efficiency. They started to get requests to onboard other teams into their flow as the management of this group has been advertising their sucess. Other groups want to implement Continuous Integration, get database unit testing and static code analysis setup, implement gates for approval, and more. The Operations team manages most of this and is happy to help other groups. But They require some things to be in place, some of which are cleaning up technical debt. Not all debt, but certain things that create additional risk or instability. Before they onboard anyone, they don't want to take on a codebase that is difficult to manage. A lot of this debt isn't difficult, but they want some good coding practices implemented. They require integrated security or a waiver from InfoSec. They want explicit index names, not system-generated ones. They want permissions granted to roles, not users. Not big things, but little items that make a system less maintainable and understandable. The same things a lot of us let creep into our codebase over time. On one hand, I thought this is an idea that will slow adoption and allow many groups to continue to operate inefficiently. They won't clean up code. On the other hand, this might be the lever that helps create a better run environment across the organization. This might help them smooth their upgrade cycles, let staff change between projects, and more importantly, reduce the overhead of communication and work between teams. I don't know how this will work over time, but I am interested to see what happens. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
