Simple Feature - Hidden Complexity

So, your application needs to send emails. It could be anything, from an updated order status to a scheduled report, a reminder, etc. Simple enough? We'll see...

When estimating the development time for sending an email, you'll typically hear one of these:

1. "About an hour." Just a subject, some text, and boom, that's it. There is no rocket science here; we do this blindfolded, hands tied while whistling Beethoven's 10th.
2. "That Depends." This is what you want to hear.

And why is that? Consider these:

• Do you want to know who got what email and when? This is handy for customer follow-ups and necessary if a customer calls you "about the email you just sent".
• Should the design be plain text or something more fancy that matches your brand?
• Is there just one language or multiple? Do we already have that information in a customer or company profile, or should it be developed?
• Should the recipient's name, an order summary or other variable content be included?
• If there is variable content, should it be localized? Consider timezone and date notation, for example.
• Are there other tools or services within your company already sending emails? If so, can we use the same server/service for sending the new emails as well?
• If we need to set up a server/service for sending the emails, do you want extra care taken to avoid spam filters as much as possible (which comes at a cost)?
• Do you want to edit email content yourself, or will a developer do it each time?
• Do you want to include timely messages, like seasonal greetings or holiday closure notices?
• What if an email address is invalid or outdated? How should you be notified of that?
• Do you want fries with that? (just keeping you alert, fries would be out of scope anyway)
• How should temporary issues, like a full inbox or unreachable servers, be handled? Send a carrier pigeon as a backup?
• Do you need to track open rates?
• Should you be able to resend an email, maybe after correcting the address?
• Should it be tested how the email will look across different email clients and devices?
• Should it be possible to send the email to multiple Recipients? For example, sending reports to more than one person or a backup colleague?
• Are there emails that should be sent to a specific email address, like invoices to invoice@...?
• Are these the kinds of emails people should be able to unsubscribe from?

And if you didn't think of these yourself, you need someone to advise you on what you need to consider. It's about understanding what's essential now, what we don't need, what can wait, and how it impacts development time and thus cost.

Sending an email is just the example I used here. This also applies to APIs, reports, user management, audit logging, authorization, scaling, administration, and so much more.

Discovering you're missing key functionalities can lead to a frustrating cycle of bumping your head and additional development. Adding functionality later on is always more expensive and time-consuming than getting things right from the start. Knowing potential future needs can also influence the developer's implementation now, avoiding future rewrites.

And even if you just want to start out by sending that plain email and nothing else, that's fine. As long as it's an informed choice and not an oversight.

Surprises are great for birthdays but not when developing software.