4 ms·

This is why I think custom software contracting and vendorization is a “noob-trap”. Software needs to be updated and maintained and you never know when you sta

This is why I think custom software contracting and vendorization is a “noob-trap”. Software needs to be updated and maintained and you never know when you start writing it what the real requirements are. If I were a taxpayer in this state I’d be angry that my money would be going to a series of middlemen (e.g. a procurement consultant, program manager on the gov side, a contractor manager, the contracting company’s cut) rather than some state employed software developer.

monadic5 6y ago
C'mon, that's Big Government. We all know that's the least efficient form of production possible. /s
lbriner 6y ago
Sorry but this is just a question of balance. Sure, it sounds like a public-sector employee gives better value but if you want to produce commercial quality then you still need management, consultancy and high quality HR with competitive salaries, otherwise you usually get mediocre developers with mediocre results. Sometimes it really is better to pay a premium on the "day rate" to get something more quickly and to a higher standard. You also often have access to better support and maintenance. You pays your money and takes your choice.
mattmcknight 6y ago
Unfortunately the pay scale for state software developers never (I almost never say never) has a proper differential over other employees with the same level of experience, meaning they are often below 10th percentile of market rate, and thus the employees that end up in those jobs tend to be among the least skilled and motivated people I've ever dealt with. Even though contractors mess up, you can fire them. What's probably better is to keep a contractor available on an hourly rate for maintenance like this, rather than pay per change order. I also find the government "requirements" process tends to create situations like this. Rather than build flexible software that puts some degree of trust in the person using it, they tend to overspecify the current bureaucratic process. In many cases, the person pushing for the software is looking to use software to enforce bureaucratic control that they have been unable to otherwise exercise, with the effect of the people the project initiator wants to use the software simply working around it. They then institute all sorts of punishments and controls to insure it must be used. This then results in the kind of insane situation we have here, where you can't do something perfectly legal because "computer says no".
- tp3 6y ago
  If you're planning on breaking out of a certain contract-type or the other will be even more ridiculous, then consider putting out a separate RFP or having some special setup that allows you to just bypass or do the RFP at a higher rate. I'd recommend putting out an RFP for every project that needs it, even though it's a small number of the projects you're doing, and use that for the next project so the future RFPs won't get wasted. Otherwise you'll always run into these problems of a small number of big companies needing to get approvals because they're the one entity. It gets complicated but there are some simple rules to follow. If you are running a non-competitive RFP then that might be okay because you are running a competitive RFP and so you get these opportunities to leverage your competitors, use one of the other competitive RFP rules for other projects, to use your competitor's RFP, etc. but you need to make sure the RFP you are running only does what the competition isn't allowed to do.
  - aksss 6y ago
    Having worked with a lot of contracted firms that do custom software development and platform customization, let’s not put them too high on a pedestal. What money you save on FTE programmers needs to be funneled right back into management talent to make sure they deliver a quality product (high utility, supportable by next contractor, quality docs, etc). Good management talent is hard to find and not something any government is known for. Consequently, next contractor probably has mondo ramp-up time deciphering what hacked pos the last guys put in with their c-team developers (cuz margins).
- deleted 6y ago
  [deleted]
- daniel-thompson 6y ago
  > the employees that end up in those jobs tend to be among the least skilled and motivated This. The job itself is terrible and as you mention the pay is terrible too. With conditions like that, I'm not surprised the product is buggy, over-budget, and difficult to improve.
- DaiPlusPlus 6y ago
kingaillas 6y ago
>than some state employed software developer. Are you willing to pay market rates to retain that developer? Or deal with the constant churn as people stay long enough to pad their resume before moving along to the next job?

monadic5 6y ago

C'mon, that's Big Government. We all know that's the least efficient form of production possible. /s

lbriner 6y ago

Sorry but this is just a question of balance. Sure, it sounds like a public-sector employee gives better value but if you want to produce commercial quality then you still need management, consultancy and high quality HR with competitive salaries, otherwise you usually get mediocre developers with mediocre results. Sometimes it really is better to pay a premium on the "day rate" to get something more quickly and to a higher standard. You also often have access to better support and maintenance. You pays your money and takes your choice.

mattmcknight 6y ago

Unfortunately the pay scale for state software developers never (I almost never say never) has a proper differential over other employees with the same level of experience, meaning they are often below 10th percentile of market rate, and thus the employees that end up in those jobs tend to be among the least skilled and motivated people I've ever dealt with. Even though contractors mess up, you can fire them. What's probably better is to keep a contractor available on an hourly rate for maintenance like this, rather than pay per change order. I also find the government "requirements" process tends to create situations like this. Rather than build flexible software that puts some degree of trust in the person using it, they tend to overspecify the current bureaucratic process. In many cases, the person pushing for the software is looking to use software to enforce bureaucratic control that they have been unable to otherwise exercise, with the effect of the people the project initiator wants to use the software simply working around it. They then institute all sorts of punishments and controls to insure it must be used. This then results in the kind of insane situation we have here, where you can't do something perfectly legal because "computer says no".

tp3 6y ago
If you're planning on breaking out of a certain contract-type or the other will be even more ridiculous, then consider putting out a separate RFP or having some special setup that allows you to just bypass or do the RFP at a higher rate. I'd recommend putting out an RFP for every project that needs it, even though it's a small number of the projects you're doing, and use that for the next project so the future RFPs won't get wasted. Otherwise you'll always run into these problems of a small number of big companies needing to get approvals because they're the one entity. It gets complicated but there are some simple rules to follow. If you are running a non-competitive RFP then that might be okay because you are running a competitive RFP and so you get these opportunities to leverage your competitors, use one of the other competitive RFP rules for other projects, to use your competitor's RFP, etc. but you need to make sure the RFP you are running only does what the competition isn't allowed to do.
- aksss 6y ago
  Having worked with a lot of contracted firms that do custom software development and platform customization, let’s not put them too high on a pedestal. What money you save on FTE programmers needs to be funneled right back into management talent to make sure they deliver a quality product (high utility, supportable by next contractor, quality docs, etc). Good management talent is hard to find and not something any government is known for. Consequently, next contractor probably has mondo ramp-up time deciphering what hacked pos the last guys put in with their c-team developers (cuz margins).
deleted 6y ago
[deleted]
daniel-thompson 6y ago
> the employees that end up in those jobs tend to be among the least skilled and motivated This. The job itself is terrible and as you mention the pay is terrible too. With conditions like that, I'm not surprised the product is buggy, over-budget, and difficult to improve.
DaiPlusPlus 6y ago

kingaillas 6y ago

>than some state employed software developer. Are you willing to pay market rates to retain that developer? Or deal with the constant churn as people stay long enough to pad their resume before moving along to the next job?