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.
Because the marketing platform is terrible. Frequent need for a full page reload to fix a caching issue. Test emails don't support email template tags without a default value. Searching for an email address is terrible slow, the upload is glitchy. Email activity is also slow and limited, sometimes I don't even know if I hit enter because I have to wait so long with no UI indicators. The pricing is also horrible with no way to purge bounce or unsubscribed emails, so they just collect and drive up your "Contact Storage" fees. The recent Sender Authentication change created unreadable sub-domains until they started to offer an advanced option again.
Yes, I emailed support about a few issues but received the blanket "What browser are you using?" when I provided full details. So I built a marketing system on top of their API and fixed those issues for our users.
I don't know if MailChimp is on its way down or what. I recently reset my phone before realizing that 2FA would be affected. Now, I was encouraged to enable 2FA, but I can't get back into my account and MailChimp isn't getting back to me about what I can do if I don't have any backup codes. I know it's a tough situation, security-wise, but I can send my passport if they need it!
Ouch, that forced transition was certainly developer-hostile, but I don't want to see Mailchimp go bankrupt just because they pulled the plug on me (and switching to Sendgrid was basically an improvement for me, anyhow).
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.
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.
Is your argument: "If you enjoy your job, you want to do it all the time, and less job == less enjoyment"?
If it is, may I humbly suggest that scarcity does not reduce enjoyment, and that looking forward to something can actually increase your enjoyment of it when you do get to do it.
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).
Easy to say, but unfortunately rarely seen in the wild, depending on the experience of the project manager. Once that product is live and climbing, no owner wants to hear talks about slowing down for reasons of better test coverage or refactoring.
I think the point is more that the slowing down is going to happen anyway if production systems are repeatedly catching on fire and people are afraid to make changes. At that point the difference is how having or not having tests will affect things in the longer term.
Indeed, but prototypes running in production or running without tests, is a symptom of other underlying problems in the organization. I feel that scope creep and lack of testing goes hand in hand for projects that are poorly managed.
Only if you are referring to perfect tests which cost zero time to write/maintain and only the tests written that eventually will catch an issue.
Otherwise, tests have a cost just like any other code. You can see this by looking at both extremes: perfect tests (described above) and useless tests. For example, tests that make your codebase too brittle, tests that don't actually test anything useful, spending too much time writing tests, spending a lot of time writing tests for precisely the code with high disposability, tests that are too coupled with the code, stupid tests that should be removed but won't be because tests tend to be append-only, etc.
Testing is an advanced topic where every +1 unit you spend on testing doesn't mean your application is now +1 unit more robust. +1 unit of time spent in tests can even mean your application is -2 units worse because testing is a trade-off.
So tests are more than capable of hamstringing your unlaunched MVP. They're also capable of being the reason you launched your MVP sooner than later. But the costs of testing are no illusion.
Some tests save you time. Some tests don't. It's perfectly possible to write a huge, fragile, heavily coupled test suite which takes days or weeks to modify when you make even a tiny change to the code it's testing.
Just as code falls on a spectrum between clean and completely unmaintainable, so do tests.
Test save you time (maybe) in the long run. But in the search for product market fit, you may conceptualize, design, build, release and then scrap a feature within the course of a month. That's not a long enough lifespan for the tests ROI (better code, fewer bugs, better architecture) to be positive.
The regression test [1] for our legacy application takes five hours to run. It takes five hours to run because it also needs to check every log message (via syslog) to ensure every transaction happened.
I can't say it saves any time, and it certainly does not have a negative cost.
[1] There are no unit tests, as there are no real "units" to test. It's a legacy code base of C and C++, using a proprietary library that no one left in the company has much experience with. Said proprietary library is considered "legacy" by the company that owns it. I've seen the code. No wonder they consider it "legacy" (it started life in the mid-80s and god does it show).
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.
