Multiple Perspectives On Technical Problems and Solutions

Multiple Perspectives On Technical Problems and Solutions” is an interesting take on engineering in general and software architecture in particular.  It starts off with:

Fundamental: engineering decision-making is a socially constructed activity

[…]

In other words, engineering (as an activity) does not have “correct” solutions to problems. As an aside, if you’re looking for correct solutions to problems, I’d suggest that you go work in a different field (like mathematics); engineering will likely frustrate you.

It then goes into dialogues and discussions, architecture review meetings, and provides a few pointers on how to get the best of those.

What Comes After SaaS?

What Comes After SaaS?” is a collection of some interesting thoughts on the evolution of the software industry, its current position and issues, and what’s coming next.

Here are a few bits to get you started:

[T]he easy availability and mass adoption of cloud-based (SaaS) technology makes advanced software systems so much easier/cheaper/faster to build that “value” is rapidly bleeding out of the software stack. Yes, software is eating the world, but software’s very ubiquity is starting to threaten the ability to extract value from software. In other words, the ability to write and deploy code is no longer a core value driver.

And:

In an era of cloud and open source, deep technology attacking hard problems is becoming a shallower moat. The use of open source is making it harder to monetize technology advances while the use of cloud to deliver technology is moving defensibility to different parts of the product. Companies that focus too much on technology without putting it in context of a customer problem will be caught between a rock and a hard place — or as I like to say, “between open source and a cloud place.”

And here’s the best part, talking about Cloud 3.0:

The next chapter of Cloud software will lead to an explosion of new vendors and offerings. But they won’t quite look the same as before — expect lots of point solutions (run by small teams or even individuals) and software as a delivery for more elaborate (e.g. human-in-the-loop) service.

This new way of doing business is still developing rapidly. But here’s a spotting guide to identify this new breed of company in the wild:

Cloud 3.0 Company Differentiators:

  • Connect from anywhere: one click auth, integrations with all major platforms with relevant data sources to power the tool
  • Open platform: complete developer APIs and export functionality — and maybe even storing core data in one or more other vendors’ systems
  • Programmatic use: many happy customers may only ever interact programmatically — no more interfaces, dashboards or logins to remember. Just value and connectivity.
  • Clear core value: most companies seem to fit in one or more of the categories below:

One or More Core Value

  • I: Best-in-Class Point Solution (e.g. Lead Scoring)
  • II: Connectivity Platform — the integrations are the product (e.g. Segment, mParticle, Zapier )
  • III: Solution Ecosystem — the core value of product might actually be other developers who happen to deployer or deliver their value through this product’s pipes.

Interestingly, Salesforce — who brought us “The Cloud” — may even be the first major window to what next generation companies look like. After all, one could argue the value to a SMB choosing Salesforce (instead of the many ways to manage sales contacts) has become:

  • A standardized schema for CRM data
  • Easy integrations with hundreds of other point solutions
  • A pool of independent contractors with familiarity of the problem space

We could imagine even faster innovation if only there were a way to establish trust with many remote vendors and workers, each offering the very best point solution in the world. 10 Million “companies” powered by the very best person in the world at their solution. Sounds a little bit like Ethereum and the token-based economy…

Eight Rules for Effective Software Production

Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com.  The whole thing is well worth a read, but here are the 8 rules to get you started:

  1. Understand the IT Mentality
  2. Do Not Mix Software Production and Development Methodologies
  3. Use Persistent Storage as an Extension to Human Memory
  4. Stop Wasting Time on Formal Time Estimation
  5. Understand the Cost of Switching Tasks and Juggling Priorities
  6. Use Architecture Reviews as a Way to Improve System Design
  7. Value Team Players
  8. Focus on Teamwork Organization

All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite.  Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions.  And looking back at all of them, I have to honestly say that they all of them were a waste of time.  The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.

Software Engineering at Google

Fergus Henderson, who has been a software engineer at Google for 10 years, published the PDF document entitled “Software Engineering at Google“, where he collects and describes key software engineering practices the company is using.

It covers the following:

  • software development – version control, build system, code review, testing, bug tracking, programming languages, debugging and profiling tools, release engineering, launch approval, post-mortems, and frequent rewrites.
  • project management – 20% time, objectives and key results (OKRs), project approval, and corporate reorganizations.
  • people management – roles, facilities, training, transfers, performance appraisal and rewards.

Some of these practices are widely known, some not so much.  There are not a lot of details, but the overall summaries should provide enough food for thought for anyone who works in the software development company or is involved in management.

 

move fast & break nothing

An interesting talk by GitHubber Zach Holman on code, teams and process – “move fast & break nothing“.  It covers everything from DO’s and DONT’s, tools, and even Blue Angels jet fighter flying squad.   (Check the link above for slides and transcript, if video is not your thing).

 

Flexible Feature Control at Instagram

Instagram

Flexible Feature Control at Instagram” article describes how Instagram controls the release of new features to groups of users.

I’ve implemented a very simple feature control mechanism before, but nothing to the sounds of this one.  Rolling out to groups of users, conditional control, geo-tagging, and more.  On top of it, non-technical users seem to be able to use for tuning the groups.  This sounds quite impressive, especially when you think of the Instagram’s user base (400,000,000+ users).

How Complex Systems Fail

How Complex Systems Fail – a very concise, yet complete paper on how complex systems fail.  It’s not system or industry specific.  Here are just the bullet points:

  1. Complex systems are intrinsically hazardous systems.
  2. Complex systems are heavily and successfully defended against failure.
  3. Catastrophe requires multiple failures – single point failures are not enough…
  4. Complex systems contain changing mixtures of failures latent within them.
  5. Complex systems run in degraded mode.
  6. Catastrophe is always just around the corner.
  7. Post-accident attribution accident to a ‘root cause’ is fundamentally wrong.
  8. Hindsight biases post-accident assessments of human performance.
  9. Human operators have dual roles: as producers & as defenders against failure.
  10. All practitioner actions are gambles.
  11. Actions at the sharp end resolve all ambiguity.
  12. Human practitioners are the adaptable element of complex systems.
  13. Human expertise in complex systems is constantly changing.
  14. Change introduces new forms of failure.
  15. Views of ’cause’ limit the effectiveness of defenses against future events.
  16. Safety is a characteristic of systems and not of their components.
  17. People continuously create safety.
  18. Failure free operations require experience with failure.

 

Alex Stamos : AppSec is Eating Security

I’m throwing this into the pile of arguments for “security and privacy are little but myths” discussions.  If top of the top companies, with multi-million budgets and hundreds or thousands of top security professionals get compromised, how realistic is it for the average Joe to protect his business?  I say – not very.

I think 80% of problems can be prevented with the 20% time and effort investment: minimize attack surface by removing and disabling everything you don’t need or use and limiting access to everything else, use layered defense where possible, use encryption where possible and strong passwords if you have to, don’t rely on security through obscurity, have log analyzers and/or intrusion detection system installed, etc.  But most importantly, make peace with the fact that being compromised is not the question of “if”, but “when”.  Prepare yourself.  Have an offsite backup and know how to restore your services in a completely new environment, if necessary.

And as far as your privacy goes, if you put anything private on the Internet, as well, prepare for it to be stolen and leaked.  If it never happens, consider yourself lucky.  Otherwise, just learn to deal with it.  It’s very unpleasant in a variety of ways, but seldom deadly.

Via EtherealMind.