Incremental design doesn’t excuse the guy adding thing #2 or thing #3 not paying attention to the whole. Nor does being a contractor excuse it. You don’t get a contract job to add some links to a page. You are contracted to modify it (regardless of what the buyer said he wanted) - and you are responsible for not making it dangerous. Even if that means you can’t take the job.
Someone reviewed the spec for this. Someone modified the page of links. Someone reviewed that modification. Someone signed off on the change.
> You are contracted to modify it (regardless of what the buyer said he wanted) - and you are responsible for not making it dangerous.
Actually, with government contracts, you are legally obligated to perform only the task assigned. Providing work to the government without the government paying for it is illegal. And you are only being paid for what's in the contract. (This is actually overall a good thing. Otherwise, large companies with better margins could easily provide free value-adds to government customers to win contracts away from small shops with small margins.)
Now, in this case, yes maybe the contractual item could have been interpreted in a way that allowed a proper page redesign. However, I would never state that as a fact without having the requirements and also receiving agreement from the government customer over such changes.
>Providing work to the government without the government paying for it is illegal.
The Anti-Deficiency Act only prohibits "voluntary" services, not "gratuitous" services. Prior to the passage of the law, it was not unusual for cash-strapped gov't agencies to accept "voluntary" services (i.e., no formal obligation to pay for them) but then pay for them later after being allocated more funds. Congress didn't like this so it outlawed the practice. However, if someone wants to donate services to the gov't and executes a written agreement to not accept payment, then it is legal for the government to accept the free services. See, e.g., https://www.gao.gov/assets/450/441639.pdf
Thanks for the important clarification. I think the relevant part for this conversation is that the work still has to be outlined within a contract, and that contract has to specify that there is no compensation. That's a drastically different scenario than pretty much any developer in a government contract situation would find themselves. It would still be illegal to do work outside of that specified in the contract!
This might be the case, but I sure wouldn’t have done it this way regardless. I would have pressed on to get the customer to revise the order, or just fixed it (criminal or not), or refused the job.
This is clearly a case where all the downsides of bureaucracy were in full effect (someone might be afraid to touch something) but not the benefits (lots of security checks and balances such as in air traffic control).
> I would have pressed on to get the customer to revise the order, or just fixed it
When "trying to do it right" means you have to go through layers and layers of bureaucracy and probably ruffle a few feathers in the process, over and over again, I can see how some people quick learn to "just do their job".
This is human behavior. We can talk as much as we want about what would be the ideal solution here, and how we would never do it, but problems like this don't happen in a vacuum and are rarely one person's fault. It's a whole system that leads to this.
Yes - this is a very broken system and that needs to be addressed.
But what I was trying to say was that by either refusing to do it outright, o doing it right (without “asking for permission”). That is - I’d rather be jailed or fired than doing this. And I hope that goes for most devs.
And none of those someones were likely the same person, nor can it be proven that they ever communicated.
Welcome to government contracting.
When I was in my sea tour, my SO hated when I said "Designed by the lowest bidder, built by the lowest bidder, manned by the lowest bidder, for the lowest bidder."
So many assumptions... first, inject twice as many levels. Then make the output text go through a system which makes it impossible to add any formatting. Add a legacy system and some procurement. Mix well.
Oh and the person signing off likely never actually sees the output.
Right, and the developer who was at the bottom of the chain might want to clean up the page a bit, but the person above him can't sign off on something like that, nor the person above him. Approval for any modifications has to come from the woman who wrote the business spec that was contracted by your boss's boss's boss and her company has allocated her to another project right now and won't be able to shift hours to handle your request until March.
I’d just make the smallest change that “fixed” the problem (in this case for example including the action title in the comfirmation, and calling the non-test vs test action something more clear etc.)
My superior would just have to solve the problem of getting the spec change cleared or find another developer. If that was somehow even seen as a problem by the superior - same thing - they’d have to find another developer.
I think you and other commentors are being generous in assuming there was a spec to review and that the work was done by a contractor.
I've seen lots of organizations try to save a buck by extending a previously existing system with in-house labor after the original contractor asked for more money to do the change. I would bet that the original contractor (if they're still involved with the project) hasn’t seen that screen because it's some homebrew patch put in by whichever administrator babysits the machines for the state government.
The problem with organizations maintaining their own rogue patches is that, if those organizations had people compentent enough to make changes well, they wouldn't have hired a contractor or bought off the shelf in the first place.
As a contractor or an employee, you do have the ability to do what you think is right despite what your employer says they want.
But only to a point. People resist perceived change. You can improve the back-end all you want, as long as you don't make unexpected changes to the front-end. This includes something as simple as a clarifying pop-up, or a speed increase of a procedure.
And being fired isn’t just a risk you should be willing to take, it’s the required course of action here. With any luck you could get a superior in trouble by going above their heads or reporting to a relevant authority.
Doing things that are immoral/dangerous/stupid because you need to eat is not an excuse.
That's a rather naive view of the work environment. There's a myriad of reasons why it is hierarchical of which not the smallest one is so people down who have a limited field of vision and expertise do not jump into decision making above their pay grade. Doing it once may be acceptable but the issue of course is that one is unlikely to know when is the time do that stick the neck out. Doing it multiple times pretty much guarantees that one would find out that he or she is imminently replaceable.
Someone reviewed the spec for this. Someone modified the page of links. Someone reviewed that modification. Someone signed off on the change.