Tuesday, October 17, 2017

Blockchain and Privacy

First, let me say I am not an expert on Blockchain. That being said, I have been following the advancements in this domain for some time.

One feature of a Blockchain is that a previously written block cannot be amended or adjusted in any way (Feel free to correct me if I am wrong).

This all makes for a very secure, distributed history of all things in the chain... 

Blockchain is becoming increasingly talked about in markets involving financial transactions...Trades and currency transactions seem to be a current hot-spot for the concept. 

Recently, I read an article (sorry I do not have the reference, but it stuck with me which is why I created this post).  

The article talked about storing contractor data and recruitment data in a Blockchain and using "smart contracts" to link contractors with potential jobs.  Someone posted it in a feed and proclaimed... "The Blockchain is going Meta".  

I have been wondering about security of sensitive private information and the ability for incorrect or bogus information to be removed.

If you consider that information in a Chain can never be deleted, how does one comply with laws such as the EUs "Right to be Forgotten" legislation  by example? 

My mind races with potential abuses to the concept of information being freely available to anyone with access to the chain.

Consider the example of skills being auto-matched to a requirement.. and the history that would forever exist about this.  I can see several pros and cons to this depending on which side of the situation you are in. 

I sincerely put this question out to experts in Blockchain... 

How DOES information get deleted, or can it (or should it)?  

It seems to me that just because you can put something in a Blockchain, maybe you shouldn't always?

I really don't know the answers.. I just have questions... 

I made this post hoping to find someone wondering.. 

What should go into a Blockchain and how we do we protect our privacy?   I think the time to talk about this is now. If you are in this field, are you having these conversations?

Based on my current understanding of Blockchain, if a country legislated a "Right to be forgotten" for any information in a Blockchain, it would be impossible without starting a brand new chain.  Do I have that right?

* references

Blockchain -  https://en.wikipedia.org/wiki/Blockchain

Right to be forgotten Legislation   - https://en.wikipedia.org/wiki/Right_to_be_forgotten



Tuesday, August 29, 2017

Stop bashing corporate leaders


  • Pictures of Leaders with angry red faces
  • "Leadership doesn't get it" blog posts
  • "Greedy Board Member" blog posts
  • Posts about "foolish management"

... the list goes on ...

Do you publicly humiliate the management or leadership of an organization you work for (employee or contract) and then later complain you can't get time with leadership or wonder why you can't connect with them?

If so.... From a purely effectiveness level... If you publicly mock the leadership of an organization, you can't really expect to have a trusting, open relationship with the same people you just mocked. 

How would you feel if the leaders started publicly mocking you?

Something to think about next time you decide you want to post a "let's poke fun at the leaders" message.



Saturday, July 29, 2017

A misunderstanding about contracts in an agile context


The Agile Manifesto contains the following words...

Customer collaboration over contract negotiation

I recently experienced a person suggesting that as agilists, we can sign contracts and then just do what feel is right and that every decision after signing should still be a negotiation. 

There are ways to make flexible contracts. I have seen contracts designed to specifically require collaboration. I have seen contracts that get regularly re-negotiation based on changing needs. 

My preference is to work with a minimal contract (or with pure collaboration if that is possible).

There is always the option to not sign a contract you cannot live with.

Signing a contract with the intent of ignoring it is not collaboration. I would argue that it is very disrespectful to the other party involved. 

I have a different word for someone who signs a contract with the explicit intent of ignoring the terms... and it isn't Agilist. 


......
Reference: Agile Manifesto - http://www.agilemanifesto.org

Wednesday, June 21, 2017

A story about a Hammer


When I was young, my father bought me a hammer.

While learning how to use it, I recall directly hitting my thumb one day. In fact, the pain was so excruciating that I doubt I will ever forget. My thumb turned a variety of colours and eventually the nail fell off.

I thanked my father last weekend.... Instead of telling me to try to learn a screwdriver as it might be easier, he convinced me to keep learning and practising and that likely I would hurt myself again. That's how we learn.

My confidence with a hammer increased considerably over time. 

Eventually, I started experimenting with other tools and their uses.  I have had the pleasure of using a variety of tools such as Screwdrivers, Drills, Mitre Saws, Table Saws, Sanders, Routers, and my favourite finishing tool.... A Bisquit Joiner.

I have built a house, build docks and decks, learned plumbing, done insulation, built furniture, and the list goes on. 

There is no challenge that scares me. I believe this is because of the lesson from my father...


When a hammer is the right tool for the job, don't let someone convince you to use another tool just because the hammer is hard to use. Stick with it if it's the right tool. Then, the confidence to use other tools will come on it's own.





Friday, May 5, 2017

A leadership question


Are you in a leadership position?

In your context, when you listen to someone talk about their leadership ability or history....

Do they talk more about leading things (projects, products) or leading people?

Would a balance be appropriate in your view?


Consider asking yourself... 

"How am I doing in this regard?"


Just a thought. 

Enjoy.

Wednesday, April 19, 2017

A calm leader in extreme circumstances


One of the most amazing IT leaders I ever met simply sat back, relaxed, and asked simple, direct questions in a friendly way while 200+ people ran around in a panic during a system outage. 

It was fascinating to observe.

His thoughtful questions let others do their jobs to realize the problem on their own. 

He remained always calm and never laid blame. 

A great memory.

--------------------------


Have you considered your ability to remain calm and let others do their work?

Just a thought.

Wednesday, March 29, 2017

Human Senses - A Conversation Aid


Have you ever talked to a room full of blank faces?

These 4 base sets of human emotions are strong in other's communication patterns. 

Listen for them as a possible way to more effectively communicate with others.

The last slide has examples of the same question asked with emphasis on different human senses.  Enjoy.

Link: Human Senses Presentation on Slideshare






Tuesday, March 28, 2017

A scary looking door



See a door you are afraid to pass through?

Consider taking a glimpse rather than passing by.









Thursday, February 16, 2017

Sprint Reviews and Stakeholders. Something worth discussing by Paul Heidema


I came across this post today from Paul J. Heidema.

It opens up an important discussion related to Stakeholders at Sprint Reviews.


Stakeholder have feelings and want to contribute as much as anyone else. We're all in it together.


Paul brings up some concepts related to getting stakeholders up-to-speed so they can best contribute at Sprint Reviews.


Give it read... 


It may get you thinking...  



What have we done to help our stakeholders feel like valuable contributors to our work?

Thank you Paul for the valuable post.



Here it is...



https://www.linkedin.com/pulse/how-effective-stakeholders-sprint-review-scrum-paul-j-heidema





Tuesday, February 7, 2017

Tech Post: Unit Testing for Distributed Systems


I recently came across this very interesting presentation and article related to Unit Tests for distributed systems and felt it was worth sharing.

Presentation:
https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan

Article: 
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf


From the technical article...
almost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software.

and this one...

in 58% of the catastrophic failures, the underlying faults could easily have been detected through simple testing of error handling code.

This sentence really caught my attention...
In fact, in 35% of the catastrophic failures, the faults in the error handling code fall into three trivial patterns: (i) the error handler is simply empty or only contains a log printing statement, (ii) the error handler aborts the cluster on an overly-general exception, and (iii) the error handler contains expressions like “FIXME” or “TODO” in the comments.

If you are working on distributed systems and are wondering where to put effort in automated testing, it might be worth grabbing a coffee and spending some time on this.

At a minimum, it might have you think about just scanning your code for the word FIXME or TODO in catch blocks and put an end to that !

There's more that I could add, but it's probably best if you just read this article for yourself.

https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan

Enjoy