Honest and collaborative companies will be as open as they can about their cash burn rate and prospects for more funding. If this aspect of the business is not done well, it can have pretty sudden and unpleasant consequences for the folks doing the work on the front lines. As a dev, you might feel like you are building a something awesome one month, and the company suddenly has no cash left to pay anyone the next.
My experience in the US is that companies can cut it pretty close between funding rounds - just a few months, and those moments can be nerve-wracking if you like what you're doing.
I'm happy to read encouragement to consider the wider group of stakeholders in the scope of testing. In many organizations, incentives are out of alignment to find issues beyond the obvious user-facing correctness ones, so "testing theater" wins, because it allows teams to declare victory more quickly. Software as a discipline would benefit from more testing attention to security, accessibility, usability, etc.
Arriving at Penn Station has benefits if you're traveling for business. Hailing a ride to get to an office within 15 minutes beats the long ride to get downtown from one of the NYC airports.
Yeah, none of the NYC airports are particularly convenient. And I'm actually usually in midtown, often on the west side, so I can just walk from Penn to my hotel. (And Penn may actually stop being its dingy self one of these days.)
> (And Penn may actually stop being its dingy self one of these days.)
That's kind of already happened. The Moynihan Train Hall just opened up recently. I checked it out recently and it's quite nice, certainly much nicer than the old Penn Station. The next time you're getting off in NYC, walk towards the back of the train you came in on and then go up to the surface, and you'll be exiting in Moynihan instead of Penn.
I haven't been in NYC for close to a couple years at this point. Some of the renovation work around the LIRR entrances was done but not anything else. I'll definitely check out next time I'm there. The drawings for the continuing renovation look quite nice too.
Agreed. Jira makes it easy to add a new field, plugin, or workflow step for a particular use case, but it is much more difficult to determine if an existing field/plugin/workflow step can be safely removed. As a result, everyone is afraid to touch it, projects accumulate cruft over the years, and it degrades the entire workflow. The problem is especially bad if there is shared ownership of JIRA, and therefore everyone feels empowered to add, but nobody feels responsible for the dirty work to clean up the mess from time to time.
My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.
I completely agree that some types of changes are much more expensive with a bare metal architecture than with cloud.
6 years ago, I worked for a company in the mobile space. This was around the time of the Candy Crush boom, and our traffic and processing/storage needs doubled roughly every six months. Our primary data center was rented space co-located near our urban office. For a while, our sysadmins could simply drive over and rack more servers. We reached a point where our cages were full, and the data center was not willing rent us adjacent space. We were now looking at a very large project to stand up additional capacity elsewhere to augment what we had (with pretty serious implications on the architecture of the whole system beyond the hardware) or move the whole operation to a larger space.
This problem ended up hamstringing the business for many months, as many of our decisions were affected by concern about hitting the scale ceiling. We also devoted significant engineering/sysadmin resources to dealing with this problem instead of building new features to grow the business. If the company had chosen a cloud provider or even VPS, it would have been less critical to try to guess how much capacity we'd need a few years down the road to avoid the physical ceiling we dealt with.
It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.
The CEO may blame a lone underling, and congress may blame a lone CEO, but congress shares in the overall blame. Regulation and stiffer penalties are needed to balance incentives so that corporations are motivated to invest in security. As things stand, executives seem to rationalize skimping on security as a smart business decision.
My experience in the US is that companies can cut it pretty close between funding rounds - just a few months, and those moments can be nerve-wracking if you like what you're doing.