What is so wrong with TDD?

This question was posted recently in Quora. I read other’s answers first and felt an itch to share my thoughts on it. Thereafter, I published it as a post in Hackernoon which caught a zillion eye-balls and heck a lot of readers time. 

This post is a re-production of that after a good couple of years now, for I think this is still relevant.

I hate TDD (aka Test Driven Development) and think there are a lot of things wrong with it. Only some of them off my mind are below.

copyright: codonomics

Top 10 FacePalm Things I Witnessed In The Enterprise World

1. When a developer proposes with beaming pride to trim error stack-trace to a few lines, to reduce logging footprint. 😭😭😭😭😭
2. When a Tech Lead does not show technical inclination to learn things. 😭
3. When a Tech Lead takes boasts of attempting to fix memory leak in enterprise java application by uploading code/memory-dump to third-party site thus breaching corporate security policy. 😭
4. When a Manager/Management is callous about blatant breach in security practices and does not take mitigation/containment plans. 😭😭😭
5. When a Program Manager has no clue about the Product Roadmap and doesn't care about the big-picture. 😭
6. When a Program Manager has no clue about the Program Roadmap and doesn't care about the big-picture. 😭
7. When a Product/Program Manager attempts to steal the credits of the technical work done by developer(s). 😭
8. When Project teams crave for individual credits over working together with other stakeholders to achieve the  big organisational vision. 😭😭
9. When the Management is focused in vendetta politics instead of working towards the program milestones. 😭😭😭😭😭
10. When developers partake in management politics of cannibalism for quick wins instead of long term team harmony and learning together. 😭😭

Got even nastier things to share? Don't hesitate to dump your thoughts over comments and maybe feel a little lighter. Cheers!

Securing Microservices in the Cloud

Securing Micro-services is a tall order objective. Like any other thing in the realm of software development, there are a lot of tings to be taken into consideration on the approach to be taken in securing micro-services. There is no panacea for all threats. And assuming even if one exists, attempting to secure every service with highest levels using a single mechanism is simply over-doing the task that dampens other non-functional requirements (performance and scale).

So what are some of the things to take into account for security? The answer to that would be to ask yourself the following questions:

• Who are the direct consumers to that service? Or is your service external-facing exposed to the internet or just an internal service?
• API Gateway Pattern is a very popular pattern for securing edge-services by handling authentication and service discovery. Each external request is signed, which provides additional layer of authentication. 
• For internal services, isn't the firewall and OS layer security good enough? In the case of containerized applications, aren't your minimalist base-images of container good enough to cut fat and have just enough processes/programs enabled to keep things secure apart from your network firewall? The alpine editions of the linux operating systems for instance wouldn't even have CURL program removing the possibility to remotely curl a service from terminal.
• It is important to keep in mind that with microservices architecture, there are often more attack paths than in a monolithic architecture. Play the devil's advocate.

• What data does the service expose? Open or Closed.
• How sensitive or confidential is your data? What do you get to loose if this data leaks? 
• Do you really want to secure your service that for instance say is serving weather data of a location, catalog of your products, traffic data of a location, etc? 

• What is the tolerance to data staleness? Or how fresh or real-time you want the data to be?
• How real-time a data you are look for?
• At what rate the change of data happens?
• What is the volume of these requests?

• How frequently is your service accessed and at what volume? 
• Put other-way what is the performance requirement for your service in terms of latency (the time it takes to process a request), throughput (the number of requests handled per second)?

• What kind of attack are you preparing your defenses for? Eavesdropping, Man-in-the-middle (MITM), SQL-Injection, Cross-Site Request Forgery (CSRF), Denial-of-Service (DoS) etc.
• The medicine depends on the illness. What security measures are to be taken depends on what threats we are attempting to thwart.

All the above questions together has its effect on what and how you secure your service. You should identify any risk boundaries first. Then you can create security boundaries that match. Each boundary can then be secured by whatever method is best. Some might only need to be restricted by what addresses are allowed through (firewall), others might need additional token or certificate based security.

Classifying systems and data is so damn boring but then it is very vital thing to do, to get your overall systems right. 

References

• OWASP
• NIST
• Security in a Microservice World
• StackOverflow: Securing Micro Services Architecture internally

Understanding Open Conversation By Example

An example of recent conversation I have had with my team member(s):
* TM : Team Member

When I was having open conversation with one of the team members (let's call him TM1), this time around in the presence of other team members for transparency's sake, another (let's call him TM2) quickly pitches in to interject:
TM2: Hey Karthik, why have such serious conversations and be hard on him? Just chill out guys.
Me (Turning to him): You are making judgement so quickly. Hmm..Have you been listening to this conversation from the beginning?
TM2: No
Me: Do yo have the context of the subject we are talking about?
TM2: No
Me: Then on what basis are you advising?
TM2: Because he is my friend.
Me: Neither he is my enemy nor you. You should park your friendship outside of this room. This room is about business, about delivery and not who is what to who. Do we understand each other?
TM2: Hmm..I'm not sure.
Me: Phew!, now allow me to finish my conversation with him without your intervention. And let's discuss post this, may be when you go out for a smoke. Deal?
TM2: Ok.

One of the challenges of #consulting and #leadership is that you got to lead by example all throughout. You make mistakes for sure but don't compromise on your value system of openness and integrity. If it means having difficult and hard conversations, you do it.

You don't attempt to win quickly (by demanding respect). You play the long term game (to earn the respect that you deserve).

Now your turn: Have you ever had a hard conversation? How have you handled it? Want to share your story, so I can pick something out of it? Pen your thoughts now..

What is -O- option in wget?

The Quick Answer

• -O flag is the short notation for the flag --output-document in wget command-line utility.
• The hypen - after the flag denotes STDOUT.

Thus, wget -O- www.codonomics.com or wget -O - www.codonomics.com prints the result returned  from that URL in your terminal output or STDOUT.

Learn By Example

• wget -O www.codonomics.com writes the output to index.html file
• wget -O custom.txt www.codonomics.com writes the output to your custom.txt file as mentioned
• wget -O - www.codonomics.com writes output to your terminal's STDOUT 

References

• Man page
• My community at StackOverflow.