Encoding vs Encryption vs Tokenization

Encoding, encryption, and tokenization are essential and distinct methodologies you can employ for the processing, safeguarding, and transmission of data. These methods help ensure the confidentiality of information, safeguarding against unauthorized access, and complying with legal and regulatory standards.

Each of these techniques plays a pivotal role in the realm of data security and privacy, offering different levels of protection and utility depending on the specific requirements and context of their application.

When designing systems, it's critical to choose the appropriate method for managing sensitive information.

Encoding: Encoding transforms data into an alternative format through a reversible scheme. An example is Base64 encoding, which changes binary data into ASCII characters. This conversion facilitates the transmission of data across platforms designed to handle text.

However, encoding is not a security measure. It can be reversed easily using the original scheme without a special key, making it unsuitable for protecting data.

Encryption: Encryption secures data through complex algorithms and keys, altering the original information into an encoded format. This process can be symmetric, where the same key is used for both encryption and decryption, or asymmetric, involving a public key for encryption and a private key for decryption.

The primary aim of encryption is to ensure data confidentiality. It turns readable information into ciphertext, which can once be reverted to its original state with the appropriate key, safeguarding the data from unauthorized access.

Tokenization: In tokenization, sensitive data is replaced with non-sensitive equivalents known as tokens. These placeholders have no meaningful value or direct relationship to the original data, stored securely in a separate location, usually referred to as a token vault.

Particularly prevalent in the protection of financial and personal information, tokenization mitigates the risk of data breaches. It is invaluable for maintaining privacy and meeting regulatory requirements, such as those set by PCI DSS. Since tokens do not hold any actual data, they cannot be used to retrieve the original information, offering a robust security measure.

Rethinking the Tech Lead Role

The role of a tech lead is often seen as indispensable in software engineering teams, guiding technical directions, making crucial decisions, and mentoring junior engineers. However, the traditional concept of a tech lead can introduce several inefficiencies and limitations that may actually hinder a team's progress and innovation. This article explores why a less hierarchical approach might better foster a healthy, empowering, and collaborative engineering culture.

The Traditional Tech Lead: Benefits and Pitfalls

Benefits of Having a Tech Lead

Tech leads provide technical guidance, ensure architectural coherence, and support the professional development of junior team members. They are pivotal in maintaining technical standards and aligning the team's efforts with broader business goals.

Pitfalls of the Tech Lead Role

1. Inconsistent Role Definition: The tech lead's role varies widely between companies, leading to confusion and misaligned expectations. This inconsistency complicates team dynamics and makes it difficult to evaluate the tech lead's effectiveness.

2. Hierarchy and Bottlenecks: Introducing a tech lead creates an additional layer of hierarchy, which can slow down decision-making and inhibit spontaneous collaboration. This setup can discourage team members from contributing ideas, feeling they must always channel thoughts through the tech lead.

3. Limited Growth for Other Team Members: When tech leads dominate decision-making, it can overshadow other team members' contributions, limiting their visibility and opportunities for advancement.

4. Risk of Burnout: The demands placed on tech leads are often unsustainable, leading to burnout and affecting their ability to lead effectively.

5. Single Points of Failure: Centralizing decision-making in the tech lead can create single points of failure, particularly if they leave or are unavailable, potentially derailing ongoing projects.

6. Suppression of Innovation: The gatekeeping nature of the role might stifle innovation, as team members might hesitate to propose new ideas or challenge existing ones.

7. Scalability Issues: The tech lead model may not scale effectively in larger teams or rapidly growing organizations, where one individual cannot feasibly mentor or manage all technical decisions.

A New Vision: Cultivating a Culture of Empowerment

Instead of relying on a traditional tech lead, a more modern approach focuses on cultivating a strong culture of empowerment, collaboration, and collective responsibility.

Key Elements of an Empowered Engineering Culture

1. Shared Values and Goals: Aligning the entire team on core principles and objectives ensures coherent efforts and direction without centralized oversight.

2. Psychological Safety: Creating an environment where engineers feel safe to take risks and admit mistakes promotes learning and innovation.

3. Collective Ownership: Decisions are made collaboratively, incorporating diverse perspectives for more robust solutions.

4. Continuous Learning: Ongoing education through code reviews, mentorship, and knowledge sharing keeps the team technically proficient and adaptive.

5. Clear Communication: Regular, transparent communication prevents information silos and ensures all team members are well-informed.

Implementing a Culture-Driven Structure

1. Highly Collaborative Teams: In mature teams, leadership can emerge organically based on the situation, with members stepping up as needed without predefined roles.

2. Project Leads for Specific Initiatives: In less mature teams, or where a temporary focus is necessary, appointing project leads can direct efforts without imposing permanent hierarchical structures.

3. Recognition and Reward Systems: Implementing systems that recognize and reward contributions across the team encourages leadership and innovation from all members.

4. Use of Supporting Technology: Leveraging tools that facilitate communication, project management, and collaboration can help distribute leadership and maintain team cohesion.

5. Transition Strategies for Organizational Change: Gradually shifting responsibilities, coupled with leadership training and team-building, can ease the transition towards a more decentralized model.

Conclusion

Rethinking the necessity of the tech lead role could lead to more dynamic, flexible, and innovative engineering teams. By fostering a culture where every team member feels empowered to contribute their expertise and take on leadership roles as needed, organizations can enhance both team morale and productivity. This approach not only mitigates the risks associated with hierarchical bottlenecks but also promotes a healthier, more sustainable work environment for all engineers. 

The Unbundling of the Developer: Specialization and its Impact

 

The days of the mythical "full-stack developer" who can do it all are fading. This trend, often referred to as the "unbundling of the software developer," has significant implications for how organizations structure themselves, design their systems, and choose the right tools.

A Landscape of Specialized Roles

While individual skillsets can vary, it's helpful to understand the common types of developers and their specialties. These roles aren't hierarchical – all require deep analytical thinking despite some engineers' penchant for debating technical superiority.

• DevOps Specialists: Masters of scripting and cloud infrastructure, these individuals glue together on-premise and cloud resources. Think of them as the offspring of developers and operations teams. Their tools of choice have shifted from Chef and Puppet to Kubernetes and infrastructure-as-code.
• Data Engineers: Close cousins of DevOps specialists, data engineers set up data pipelines, manage data quality, and build ETL (Extract, Transform, Load) jobs for data warehouses. They typically favor Python and SQL.
• Backend Engineers: The workhorses behind the scenes, backend engineers build APIs, internal libraries, features, and core application logic. They're often polyglots but primarily work in systems languages like Go, Rust, Java, or C++. Senior backend engineers might handle deployments, but larger organizations often have dedicated Site Reliability Engineers (SREs) for that.
• Site Reliability Engineers (SREs): Found primarily in larger organizations, SREs blend production engineering with DevOps. They have intimate knowledge of how applications are deployed, updated, configured, and debugged. They ensure applications meet service level agreements (SLAs) and are often on-call for emergencies.
• Data Scientists: These experts model and experiment with big data. They typically wield Python and machine learning frameworks but also possess data cleaning and querying skills using databases. Their specific skillset varies based on the organization and their level of statistical and machine learning expertise. Think Jupyter Notebook as their comfort zone.
• Machine Learning Engineers: Taking data science a step further, machine learning engineers define and program complex models at scale. They design and implement features like feature stores and serving infrastructure, often utilizing Python with high-level bindings and C++ for hardware acceleration.
• Mobile Developers: Experts in device-specific APIs and design, mobile developers might also handle mobile testing, and CI/CD (Continuous Integration/Continuous Delivery) if their codebase differs significantly from the web or application stacks. Languages of choice include Kotlin, Swift, or other mobile-specific options.
• Front-End Developers: Masters of the ever-evolving JavaScript toolchain, this category is vast enough to warrant further sub-categorization. Some focus on UI/UX, accessibility, or design, relying heavily on HTML, CSS, and JavaScript. Others specialize in building progressive web apps (PWAs) or single-page apps (SPAs) with frameworks like React or Vue. Still others handle lower-level tooling for building and delivering front-end code through CDNs.
• Data Analysts: Skilled at crafting complex SQL queries and transforming data, data analysts use data to answer business questions. While some might use Python, SQL reigns supreme for them. They often favor tools like dbt, built specifically for SQL development and data transformation.
• Database Administrators (DBAs) and System Administrators (SysAdmins): A rarer breed thanks to cloud computing, DBAs and SysAdmins used to manage on-premise infrastructure like databases (MySQL, Oracle) and IT setups (software appliances, Outlook servers). Many of their responsibilities have been automated through code or shifted towards Data Analyst and DevOps roles.
• Software Engineers in Test (SET): Responsible for testing and QA tools and infrastructure, SETs build and maintain testing infrastructure in larger organizations. Smaller organizations might delegate manual or semi-automated QA testing to these roles.

Final Thoughts

The unbundling of the developer creates a specialized landscape of talent. By understanding these diverse roles and their specialties, organizations can design better team structures, choose the right tools, and ultimately build more efficient and effective software development workflows.

Alternatives to Estimating Bugs

This question frequently pops up, especially when onboarding new teams. Let's first level-set what we mean by "bugs" in this context. A bug is a software defect that causes undesired and unexpected behavior.

Here are some reasons why including bugs in estimations might not be the best approach:

• Unpredictable Complexity: Bugs are inherently complex. As Bob Hartman famously said, "There are only two sizes for defect fixes: trivial (because I already know what's broken and how to fix it) or infinite (because I have no idea what's broken or how to fix it)."  Estimating something with an unknown root cause and solution is challenging.
• Limited Business Value: Bugs are flaws, not features. Ideally, customers shouldn't pay extra for fixing what should have worked from the start. While critical bugs require immediate attention, fixing them should be seen as part of the original development effort, not something with separate value.
• Misleading Metrics:  Estimates are meant to be forecasts. Estimating bugs can distort metrics by double-counting effort.  The original user story should have already accounted for the possibility of bugs. Spending time estimating a bug's complexity might be better spent fixing it directly.
• Focus on Fixing, Not Estimating: If a bug is critical, it needs to be fixed ASAP, regardless of the time it takes. Prioritize fixing critical bugs over estimating them.

Why Estimating Bugs Can Impact Your Scrum Process

The Scrum Guide doesn't prescribe specific estimation techniques, allowing teams the freedom to choose what works best.  However, some argue against estimating bugs because it can negatively impact Scrum practices:

• Unpredictable Velocity:  Estimating bugs can make velocity an unreliable measure of predictability.  Even with a good team velocity, unexpected bugs can derail sprint plans.
• Focus on Delivery Over Value:  If the goal becomes meeting pre-defined velocity through bug estimation, it can overshadow the true value delivered in each sprint.

Alternatives to Bug Estimation

• Preventative Measures: Implement strong quality checks like TDD, pair programming, and CI/CD pipelines to catch bugs early and minimize their impact.
• Prioritize Bug Reporting: Encourage clear and detailed bug reports with evidence to aid in prioritization and estimation during refinement meetings.
• Handle Bugs During Sprints: Decide whether to fix low-priority bugs encountered during development immediately or create a backlog item. For critical production bugs, involve experts to estimate the effort and update the estimate as work progresses.
• Allocate Dedicated Bug Fixing Time: Set aside a predefined amount of time within each sprint specifically for bug fixing. This could be a fixed percentage of the team's overall velocity (e.g., 5%) or a dedicated buffer in the sprint schedule.
• Placeholder Estimates: Consider using a placeholder estimate, like 0.5-1 day, for each bug. This approach, suggested by Jeff Sutherland (co-creator of Scrum), leverages the fact that many bugs are relatively quick to fix (as evidenced by Steve McConnell's claim in his book Code Complete that 85% of bugs are fixed in under a few hours). This simplifies estimation without overly inflating effort.

There are strong arguments against estimating bugs.  These are just a few examples. While Scrum allows flexibility in estimation techniques, considering the arguments above, focusing on quality practices and efficient bug handling might be a more effective approach for your team. 

Samsung's Galaxy S4 is still top dog with CR

Consumer Reports is still the buying guide of record for many consumers in older age demographics, and the not-for-profit group recently took a look at Apple's new wares. While Consumer Reports has historically been pretty rough on Apple gadgets, it came away from its iPhone 5s and iPhone 5c tests fairly impressed, giving each handset a respectable score. Where the flagship iPhone 5s is concerned, Consumer Reports found a happy surprise in the Touch ID fingerprint scanner, which it said was surprisingly reliable. It also said the 5s camera is better than ever and that the iPhone 5c is a “compelling offering for budget-minded buyers.” Despite all that praise, Consumer Reports still thinks that Motorola's latest Droid handsets are a better buy.

The group had plenty of good things to say about both new iPhone models, and it was also a big fan of Apple's new iOS 7 software. Siri enhancements and the new Control Center were areas of particular interest. Consumer Reports says that the iPhone 5s and iPhone 5c both fall short when it comes to battery life, however, and that the smaller screens are a big drawback compared to devices from Samsung, LG and HTC.

As such, CR recommends that consumers purchase the Droid Maxx, Droid Ultra and Droid mini over Apple's handsets. The impressive battery life and larger displays are among the top reasons for the recommendation, and Consumer Reports was also a big fan of Google Now, Active Notifications and the ability to have mobile notifications display on a connected computer.

In the end, however, Samsung's Galaxy S4 is still Consumer Reports' highest-rated smartphone of the year.

I absolutely agree with CR's assessment.

Why I love my Android phone over my wife's iPhone 5

I converted over to an Android phone, about 2 years ago, when I was constantly saying to myself "I wish I could ________ on my phone". I decided that moving to a much more open platform like Android would rid me of the limitations imposed on the iPhone by it's original creators.

So, what are some of the things that my Android phone can do that my wife's iPhone 5 can't? Here goes:

1) Large screen: Firstly, I love the larger screens available on Android handsets. I agree that you don't necessarily need a larger screen if all you are doing is texting and taking calls. But if you plan on using your phone for any real work, then the larger screen certainly makes a difference. Even Apple "agrees" that a larger screen is beneficial, which is why the iPhone 5 has a larger screen than the 4. But to me, stretching it lengthwise wasn't enough. They needed to go wider. Which I'm sure they will do with the iPhone 7 or 8.

2) Alternate Keyboards: There are so many shapes and sizes of desktop keyboards, so would a phone not allow you to change the shape/size of the on-screen keyboard? Typing on a tiny phone keyboard isn't anyone's idea of fun, so it's great that Android provides so many options to make it as painless for people as possible and super easy to install. Personally, I love the Swiftkey Flow, which allows for swiping on the keyboard. It's a personal preference, but why not give users an option to enter data?

3) Control It All: I also love the ability to control "any" feature of the phone through apps. On my Android phone, I can automatically turn settings on or off for certain applications by location, time of day, and pretty much any other condition you can think of. For example, when I arrive at work, my phone can automatically flick on the Wifi and make sure I'm connected to the network, thereby saving precious airtime. Or I can have the phone automatically go into vibrate mode at 10:00 PM when I'm at home so it doesn't wake anyone up at home.

4) Removable Battery: I have had some very long days in the past and being away from my desk made it difficult to keep my phone on a dock charging. So I have the luxury of carrying around a spare batter that I can pop into my phone whenever I need it to keep me going.

5) Control Your Phone: This one is a little more out there, but I've gotten use to being able to control my phone from my computer. Why would you want to do that, you ask? Well sitting at my desk, if I get a text message or other message on my phone, instead of grabbing my phone to read it, the message comes up right on my desktop, and I can respond right from my desktop. What a convenience when you spend the bulk of your day in fron to of your desktop.

6) Micro-USB: If you're like me, you have a drawer full of USB cables, and if you can't find one, you can always buy another one at any street corner store. Using one cable that can charge my phone, my tablet or my Beats Pill portable speakers is extremely handy. I use the same cable to charge my Bluetooth earpiece. Unfortunately, the iPhone 5 uses a proprietary connector instead of the micro USB. So if you're at a party and don't have your proprietary cable with you and you run out of juice, better hope another guest has an iPhone 5 and has a cable handy. And an iPhone 4 won't cut it because that connector is also different than the iPhone 5.

7) Attaching Files: Apple doesn't gamble on immature technologies, so perhaps it's understandable that the company has yet to include this new-fangled thing called "email attachments" on its iPhone 5. It's so new and probably just a fad, right? Android allows you to attach any files you want to any email message. Whether you are using the Gmail app, its stock email app, or a different email client, there's always a prominent attachment option, and when you hit it, you're able to browse your gallery, your file system, or any other apps you have installed that organize files (Dropbox). If you plan on doing any work on your phone, then how can you live without this feature?

8) Share: With Android, every relevant app from the browser to the photo gallery includes a share button. When you tap share, you're given an extensive and universal list of apps you can share with. That list grows depending on what software and services you have installed. So if, for example, you join Pinterest and install its app, you can share directly from any app with a share button. With my wife's iPhone she can only share to those services that Apple wants her to share with. The iOS photo gallery can only be shared on Facebook, Twitter, Email, and messaging. So you can't post to Google+ or Pinterest.

9) Visible File System: Try plugging an Android phone into your PC and mounting it as a storage device. You'll have access to all the files and folders, just as you do when you browse through your Windows computer's C drive. So, if you want to copy a raft of MP3s or PowerPoint presentations to your Android handset, you can just drag and drop them. So what happens when you plug the iPhone 5 into your PC? You get access to the digital camera (DCIM) folder only so all you can do is drag and drop pictures.

10) True App Integration: On the Android, when you click to open a particular file you can choose what app to use with that file and optionally memorize that selection. For example, clicking on a picture you could choose to open it in a different program - perhaps you needed to edit the picture. With iOS, the only way to open a picture into a different program is to launch the program first, then browse to the picture you want to open. What a clumsy process.