How do I grow my company's software practice?
September 13, 2016 5:33 PM Subscribe
I'm at a very small company trying to bring their tech practice internally, they have no methodology or really any concept of how to develop software. They've previously relied on outside consultancies to do all their development. They're treating me like an outside consultancy (just get things done), how do I change this and grow them a viable team? I feel as if more I excel at development, the more they want to use me for development.
The company is great and willing to listen to things, however they have NO idea of how to develop software. That's fine, except they have a lot of software under development by a number of different consultancies. Think different JIRA boards, different architects, etc. When I got on board I was originally supposed to lead with "some development" which turned into "here is your task list of development tasks that will change everyday."
I'd like to grow the position and I realize that no company is agile, or does things the right way, whatever that may be, but I also see that a lot of things that they are unhappy with their current outside developers are the result of technical debt. This isn't their fault, I've been on the agency side so I know that they just get things done and don't see any value in work they aren't paid for, such as refactoring really bad code. Its get it done and move onto the next ask.
Any ideas on how I can help instill this? This is also a very, very small firm if that matters. They have a sizable devops team (with no developers) that leads things and they seem content with leaving as much as possible to the outside agencies.
The advice might simply be to get my work done and don't try to improve things. That's fine, and I know plenty of organizations that aren't institutionally equipped to be a software company. I just have run large software projects and worked at large organizations that have run successful large software projects and feel as if I could also do this here, if only I could somehow get through to non-tech people. I'm used to reporting to a CTO type person who probably is as out of development as I was, but realized that development was more then an email with a list of tasks.
The company is great and willing to listen to things, however they have NO idea of how to develop software. That's fine, except they have a lot of software under development by a number of different consultancies. Think different JIRA boards, different architects, etc. When I got on board I was originally supposed to lead with "some development" which turned into "here is your task list of development tasks that will change everyday."
I'd like to grow the position and I realize that no company is agile, or does things the right way, whatever that may be, but I also see that a lot of things that they are unhappy with their current outside developers are the result of technical debt. This isn't their fault, I've been on the agency side so I know that they just get things done and don't see any value in work they aren't paid for, such as refactoring really bad code. Its get it done and move onto the next ask.
Any ideas on how I can help instill this? This is also a very, very small firm if that matters. They have a sizable devops team (with no developers) that leads things and they seem content with leaving as much as possible to the outside agencies.
The advice might simply be to get my work done and don't try to improve things. That's fine, and I know plenty of organizations that aren't institutionally equipped to be a software company. I just have run large software projects and worked at large organizations that have run successful large software projects and feel as if I could also do this here, if only I could somehow get through to non-tech people. I'm used to reporting to a CTO type person who probably is as out of development as I was, but realized that development was more then an email with a list of tasks.
i struggled with your sitch in recent jobs...
some qualities of code that could be used in your 'definition of done':
(1) 'functionally correct' and probably not even edge cases matter very much.
(2) the calendar
I think illuminating any new technical debt can be pretty smart, if handled diplomatically. I think mentioning any old technical debt gets one labelled as an excuse-maker - just factor that debt into your estimates silently.
this seems pessimistic - but is my real life experience: with code, the company will *always* pay now, or pay later. that's the way of it. management will always take the 'later' side of that bet. It's too hard to effectively describe that when a better definition-of-done is deferred (i.e. crossing that bridge when we come to it) it's more expensive than it might have been.
Consider, The Mythical Man Month is forty years old, and we still have management teams trying to throw more devs at issues at the eleventh hour. Are they going to listen to Cunningham, or Fowler, or Beck, or...
so...maybe take it easy and bust out some high-profile easy ones in the near term.
posted by j_curiouser at 9:33 PM on September 13, 2016 [1 favorite]
some qualities of code that could be used in your 'definition of done':
- functionally correct
- secure
- robust
- maintainable
- fast
- testable
- tested
- extensible
- api documented
(1) 'functionally correct' and probably not even edge cases matter very much.
(2) the calendar
I think illuminating any new technical debt can be pretty smart, if handled diplomatically. I think mentioning any old technical debt gets one labelled as an excuse-maker - just factor that debt into your estimates silently.
this seems pessimistic - but is my real life experience: with code, the company will *always* pay now, or pay later. that's the way of it. management will always take the 'later' side of that bet. It's too hard to effectively describe that when a better definition-of-done is deferred (i.e. crossing that bridge when we come to it) it's more expensive than it might have been.
Consider, The Mythical Man Month is forty years old, and we still have management teams trying to throw more devs at issues at the eleventh hour. Are they going to listen to Cunningham, or Fowler, or Beck, or...
so...maybe take it easy and bust out some high-profile easy ones in the near term.
posted by j_curiouser at 9:33 PM on September 13, 2016 [1 favorite]
When you say that the company is trying to transition to internal tech work, who is championing that change?
I think you've started to tug at the start of the problem here. There should be someone at the management level who you can work with to start building this internal group. The big problem I see here is that there isn't much support for working on any kind of process change. It'll be really difficult to advocate for those improvements without backup.
Is there someone in leadership that you can identify who would be interested in helping you? Could you help create or become the CTO?
posted by thebigdeadwaltz at 10:45 PM on September 13, 2016
I think you've started to tug at the start of the problem here. There should be someone at the management level who you can work with to start building this internal group. The big problem I see here is that there isn't much support for working on any kind of process change. It'll be really difficult to advocate for those improvements without backup.
Is there someone in leadership that you can identify who would be interested in helping you? Could you help create or become the CTO?
posted by thebigdeadwaltz at 10:45 PM on September 13, 2016
> plenty of organizations that aren't institutionally equipped to be a software company
This is a great insight, I have to say.
I'm going to suggest that continuous improvement of the process is the way to go. Don't try to implement everything in a day. My first step would be to break the work into sprints - "After a few sprints, I'll be able to give you pretty good estimates of how much work can be done every two weeks. But we need a contract. I guarantee I'll get the predicted work done, you guarantee you won't change my sprint backlog after the sprint's started. Deal?"
If you can't get them on-board for better estimates, a very obvious benefit for the business, then they're probably irretrievably broken.
posted by Leon at 4:50 AM on September 14, 2016 [1 favorite]
This is a great insight, I have to say.
I'm going to suggest that continuous improvement of the process is the way to go. Don't try to implement everything in a day. My first step would be to break the work into sprints - "After a few sprints, I'll be able to give you pretty good estimates of how much work can be done every two weeks. But we need a contract. I guarantee I'll get the predicted work done, you guarantee you won't change my sprint backlog after the sprint's started. Deal?"
If you can't get them on-board for better estimates, a very obvious benefit for the business, then they're probably irretrievably broken.
posted by Leon at 4:50 AM on September 14, 2016 [1 favorite]
The company I just retired from is on the cusp of changing from a one-programmer (me) operation to a multi-programmer model. It's hard. Just getting version control up and running so that programmers can cooperate on the same program has been difficult. We/they are in the health insurance business, and there has been a big increase in data security requirements as well taking up the assets available for IT management.
In our situation, one of the first things to get organized was the change process. It used to be "send SemiSalt an email" and SemiSalt would fix. Problem solved. You need a formal change process with prioritization, assignment to a programmer, etc down to deployment). Your probably can't have all the bells and whistles you find in books, but it's the beginning of having processes of all kinds for development. Also, you need to manage expectations in the organization. "No, the fix will not be in by noon, we only deploy new versions overnight." (Unless the big boss approves an exception.)
posted by SemiSalt at 9:53 AM on September 14, 2016 [1 favorite]
In our situation, one of the first things to get organized was the change process. It used to be "send SemiSalt an email" and SemiSalt would fix. Problem solved. You need a formal change process with prioritization, assignment to a programmer, etc down to deployment). Your probably can't have all the bells and whistles you find in books, but it's the beginning of having processes of all kinds for development. Also, you need to manage expectations in the organization. "No, the fix will not be in by noon, we only deploy new versions overnight." (Unless the big boss approves an exception.)
posted by SemiSalt at 9:53 AM on September 14, 2016 [1 favorite]
Do you use different languages? Different frameworks? Do you even have posession of your code, or is it at your contractors' shops? Do you even own the code?
When you get your development task list, you've gotta say "let's outsource these, or hire a coder; it'll be faster in the long run if I manage our software as a whole rather than be just another dev."
Start documenting how you could save time, money, stress if you had some practices in place, even if it's a crude estimate.
Karl Wiegers' Software Process Improvement in Web Time has some good advice.
posted by at at 1:18 PM on September 14, 2016 [1 favorite]
When you get your development task list, you've gotta say "let's outsource these, or hire a coder; it'll be faster in the long run if I manage our software as a whole rather than be just another dev."
Start documenting how you could save time, money, stress if you had some practices in place, even if it's a crude estimate.
Karl Wiegers' Software Process Improvement in Web Time has some good advice.
posted by at at 1:18 PM on September 14, 2016 [1 favorite]
Response by poster: Well, at the risk of publicly answering this question, I did my best and it did not work out. They just wanted work done, and had no interest in improving processes. I took a very, very gentle process, here is what I did:
1. Establish credibility by simple pushing out code and ignoring process so they knew I could get work done and didn't want to spend all day talking about how to do things "right."
2. Avoid saying there was a "right" way to do things, and simply suggest that in the long-run technical debt will add up and making things clear if there was a delay due to, "just get this done please." Trying my best not to point fingers.
3. Move away from FTP'ing files individually to the server (!? people do this ?!) and using source code
4. Establishing documentation and processes on how to deploy code
5. Very, very gently try to move to a daily standup that wasn't just a boss telling us what to do
6. Convincing them that agile didn't involve moving dates around randomly and completely new development on systems we haven't touched internally will need a discovery process to even be able to accurately estimate software
7. Telling the Big Boss that testing on staging servers before developers said it was okay and sending random all caps emails stresses everyone out, that we will send out a "ready to test" note after we verify deployment went ready as planned
8. That pushing big vendors like Salesforce to come up with a plan if there was an outage (?!) just wastes everyone time and if it is that critical we need to develop systems so that we can deal with a vendor outage, even if the solution is non-technical
Anyway, it went a bit beyond that but they were not a software shop nor do I think they can become it. As I said earlier, I was worried institutionally they weren't setup to deliver software, and they weren't. As it got the point where I spent more time trying to make things look like they weren't developer's faults, and did all I could to mitigate finger pointing, I gave up.
Also another warning sign, I found out they went through a lot of developers quickly (two weeks or so before canning them), which I should have walked out when I first found that out.
posted by geoff. at 12:52 PM on November 28, 2016
1. Establish credibility by simple pushing out code and ignoring process so they knew I could get work done and didn't want to spend all day talking about how to do things "right."
2. Avoid saying there was a "right" way to do things, and simply suggest that in the long-run technical debt will add up and making things clear if there was a delay due to, "just get this done please." Trying my best not to point fingers.
3. Move away from FTP'ing files individually to the server (!? people do this ?!) and using source code
4. Establishing documentation and processes on how to deploy code
5. Very, very gently try to move to a daily standup that wasn't just a boss telling us what to do
6. Convincing them that agile didn't involve moving dates around randomly and completely new development on systems we haven't touched internally will need a discovery process to even be able to accurately estimate software
7. Telling the Big Boss that testing on staging servers before developers said it was okay and sending random all caps emails stresses everyone out, that we will send out a "ready to test" note after we verify deployment went ready as planned
8. That pushing big vendors like Salesforce to come up with a plan if there was an outage (?!) just wastes everyone time and if it is that critical we need to develop systems so that we can deal with a vendor outage, even if the solution is non-technical
Anyway, it went a bit beyond that but they were not a software shop nor do I think they can become it. As I said earlier, I was worried institutionally they weren't setup to deliver software, and they weren't. As it got the point where I spent more time trying to make things look like they weren't developer's faults, and did all I could to mitigate finger pointing, I gave up.
Also another warning sign, I found out they went through a lot of developers quickly (two weeks or so before canning them), which I should have walked out when I first found that out.
posted by geoff. at 12:52 PM on November 28, 2016
This thread is closed to new comments.
posted by sammyo at 5:56 PM on September 13, 2016 [2 favorites]