1_800_UNICORN

Re: source control, this was also written in the year 2000...

At the end of the article the author states that FMT has gained some widespread acceptance in the past 6 years. Her experience is from 2012, when it was still a relatively obscure treatment.

Wow, this is a big deal! Great move by Twilio, bringing together the premier SaaS SMS provider and the premier SaaS transactional email provider under one roof.

It's only too bad that SendGrid has struggled to get its marketing email solution off the ground in a meaningful way. If anyone was going to eat MailChimp's lunch, SendGrid would be my choice as top contender. And yet despite SendGrid releasing many iterations of their marketing email solution over the past 5 years they've never seemed to get a lot of success outside of their bread-and-butter transactional email vertical. Their marketing solution brings in less than 20% of total revenue last I heard.

Developer tools: Twilio, Heroku Consumer software: TurboTax

I know that TurboTax is a controversial choice because they are incentivized to fight to keep tax law complicated, but if we ignore the political context, their software works beautifully well. It never does anything I don't expect, when I need more time on a section it's easy to drop out and revisit later, and I always feel confident at the end that I've filled out my taxes correctly.

I think my head might explode if I ever see that in reality.

At least in the United States, I see exactly 0 chance of this happening in the current cultural and regulatory system we operate under. The average American worker is just lucky that they even get 2 days off during the week at this point.

If I found a political candidate who advocated for mandatory vacation of 4 weeks or more per year, and/or less work-hours per week, I'd give them my vote in a heartbeat. A change of that magnitude for the average worker would reap incredible social benefits for all of us.

I love the detail-oriented approach to this. Tracking jQuery usage and slowly removing components from their custom jQuery library are both really clever strategies.

If you're an early-stage startup that's still determining product-market fit, then it's completely fair to eschew tests and accumulate tech debt; you're at a higher risk of running out of runway before you've even proven that your business works.

As soon as you have enough users that an outage poses a significant risk to your business, you need to invest in either refactoring to reduce tech debt, or a rewrite. And you NEED to add tests, and a robust deployment process that tests changes at multiple stages with monitoring on the basics (server speed and memory usage, database error rate, etc).

OKCupid got lucky in this case.

I had a job offer from the StatusPage guys a few years ago that I turned down (shortly before their acquisition by Atlassian, d'oh!). The feature set is relatively simple, but the underlying software is very complex. They need to be reliable enough and robust enough to work when other major sites go down, which is no easy feat. I'm sure that like most products they started simple, but to scale to any large meaningful customers they had to put a lot of complex engineering in place.

Late to this thread, but I loved this article because it put something into perspective for me... my New England boarding school had a swimming requirement, and was proud of its longstanding tradition of requiring all graduates to be able to swim. It makes sense given the context of when it was started and the extent of people's ability to swim.

For the last 5 years I've worked primarily with startup CTOs and enterprise directors/VPs to build teams practices XP, lean product development, and user-centered design.

My advice to them, and my philosophy on this topic, is that technical debt is just that- debt. It's not a dirty four-letter word to be avoided, it's something to be managed the way you manage actual financial debt. There are some projects where the software you build will be self-contained (no dependencies), will require minimal changes in the future, or it may have a short shelf life (e.g. it's a stopgap before you cut over to a new system). In these scenarios, accruing technical debt isn't the worst thing in the world if it allows you to reap business value faster.

When you're building software that's going to live long-term, or that drives core parts of your business (and therefore will need to change frequently as your business changes), technical debt needs to be tackled early and often. It's ok to accrue technical debt in the short term ONLY if you make that decision consciously knowing that you'll need to address it later (e.g. I had a client that needed to release their software for a trade show, so we accrued tech debt and created tasks to track every piece of debt we'd want to tackle later, and then prioritized that work immediately after the trade show).

That said, it's also important to be clear about what constitutes tech debt vs what is over-optimization. Outside of libraries and frameworks, I don't really need the software to be "perfect". I need it to be clear enough, tested thoroughly enough, and easy enough to change to maintain a high velocity. If a part of the code has become spaghetti-like, or if we see code duplicated more than 3 times, or if we have disparate code that's too closely coupled to easily make changes, that's technical debt worth tackling.

The vast majority of organizations I've worked with typically think much shorter term, which is why they find themselves repeatedly accruing technical debt to the point where changes to the system occur at a snail's pace. It takes a lot of discipline, and coordination between IT and business, to practice what I'm describing, but that's the ideal that I strive for and advise my clients to strive for.

I just want to remind folks that there are, in fact, organizations for whom the open plan actually works. I've spent the last few years practicing XP, on a collaborative team that includes PM, UX, QA, and devs, and we work in an open plan with no complaints. We find that it REALLY helps us minimize meetings and email/Slack since we can quickly turn to the person we need, ask our question, get an answer, and get back to work. As a developer it's hugely refreshing to be able to easily ask for advice or input from the rest of the dev team in a rapid way.

The reason I mention this anecdote is not to dispute any of the studies... I understand the difference between anecdotal evidence and quantitative evidence. Just a counter-point to the inevitable echo chamber of complaints about open floor plans being inhumane, a money-grab, etc etc.

I'm very confused...

"Errors discovered through Instabug are most likely to be resolved within 24 hours of being reported" is one of the TL;DR points, but only ~1.5% of bugs are resolved within 24 hours.

Very interesting read. I did a double take that a lack of Cesium-137 meant "post-1980" (not "pre-1980") since the levels have dropped off since the testing in the 50s and 60s.

The "Humanity" section has left me with a deep chill. I've already been in an existential mood the nature of life in the modern age, and now I've got the end of humanity to think about too...