rickbad68

A case sensitive filesystem doesn't require you to hit shift either if you just call the directory "programs". Also, there are many ways to save your pinky from moving the huge distance to the shift-key other than an arbitrary restriction on all file names in the file system..

It sounds to me like the author had a severe anxiety attack for the first time. And just throwing out a wild guess that they possibly had recently experimented with ayahuasca or some other form of DMT.

In other words, a rewrite is never actually that. There should be a better word we use for this, like 'replacement'

This seems such a weird study. Names are important, but not so much as what is being named. In one sense, names become easy given a properly abstracted design. Further, it’s not names so much that are paramount to program comprehension, but more the quality of the design. With a bad design that doesn’t properly separate concerns it won’t be possible to come up with good names because functions/data structures will represent multiple concerns. Any time names are controversial it probably indicates a design problem, even for unique/complex abstractions, there is usually a name which everyone agrees is the perfect name for a thing..

This example is not good for talking about naming as there is no proper design which would have a function like this. In any proper design there would always be a separate function for each of the concerns.

I would argue the friends spin is probably more reliable, depending on the friend of course, as at least they would not be motivated by ratings or money and probably are not intentionally trying to cultivate any certain biased viewpoint in you.

This is absolutely false. Exposure to a higher number of viruses might increase probably of an infection, but a single virus can certainly lead to a full blown infection in an individual.

LOL

Other common terms for this are sanitization or redaction

Ya, I have both twice as many answers as questions and twice as many questions as answers. But keep plugging away guys, you'll get there.

It seems the OP is interpreting Bezos mandate as if he were talking about the interaction/communication between actual teams (people) as opposed to between each teams software service(s). Whereas there are parallels between these, I'm pretty sure Bezos wasn't saying anything about inter-team communication. It sounds like they already had a good company organizational structure but there were no limits on how services used each other, which would result in tight, often-hidden coupling that would be too complex to manage.

My guess is this was the thinking behind the mandate, limiting all inter-service coupling to a single, well-documented interface prevents the whole system from devolving into a big ball of mud; primarily because it forces all dependencies to be explicitly declared and documented in the same way.

Totally agree. How many times have I seen Tech Debt as a task to be completed in some future sprint (ya right), or seen it as the title of a category in a dev schedule containing missing product features.

Tech debt is such a general term it does more harm than good, and is often abused by people that have no clue what their actual tech debt may be..

It also implies that someone knew what the price tag was in the first place to accrue the debt, which they most likely didn't. No one knows what needs to be built or how to build it beforehand, except maybe NASA, this evolves along the way.

a practice of constant refactoring..

In my experience often the term 'technical debt' will be hijacked by product-oriented folks resulting in feature debt being presented as tech debt.

But the requirements were to allow filters to be configured on users and groups, which would require more info in your data structures. This doesn't meet the specified requirements.

Plus even with it not meeting the requirements, it is confusingly presented, and is filled with terminology related to the implementation rather than the domain. Where's a group definition? How would you configure a filter for a group? Or a user for that matter. (Answer: you would require a much more complex data model, and functions to access and modify it).

I'll stick to OO for the top level paradigm I use until something better comes along.

OO being dead is fake news perpetuated by ignorant know-it-alls.

This trivial example does not illustrate the usefulness of OO design. Extending the example imagine the requirement is that the target of an email may be either a single user or a group of users, and in addition, email filters can be configured for both individual users and groups of users

Leading to an OO class design roughly like this: (there are other possible OO designs, but this illustrates the point)

// Send an email to a specific user or a group of user taking into account both user and group level filters.

sendEmail(Email, EmailDestination)

class Email {Title, Body, Attachments}

interface EmailDestination {

   Iterator<User> getRecipients(Email); 
   List<Filter> getFilters();

}

class Group implements EmailDestination {

   // returns group filters
   List<Filters> getFilters();                 
   List<User> getMembers();

   // returns all recipients after applying group and 
   // individual recipient filters
   List<User> getRecipients(Email);  

}

class User implements EmailDestination {

   // returns user specific filters.
   List<Filters> getFilters();                          

   // returns itself unless filtered
   Iterator<User> getRecipients(Email);   

}

how would this look with a procedural design?

spf13/cobra spf13/viper joho/godotenv mattes/migrate postgres go-pg/pg gorilla/mux gorilla/sessions net/http html/template