October 29, 2014
You get better feedback if you feedback process is based on Lean/Kaizen in other words it means you have a culture of continuous improvement with no blame, no pointing finger and learning.
If You dont have the right culture around feedback could just be a form of trade of politician manipulation. You do provide better feedback to people if you try to wear they sues and think about they on they experiences. You will have success most likely if you help the person to figure out whats going on with her/him. Feedback is about self-awareness, people from outside maybe have a better vision of our problems but that does not mean they know what is the solution.
October 23, 2014
The IT Industry have some common ground ideas, but often ideas get mixed with different interpretations of the terns and practices.
There are company that say stuff like an Java Architect or .NET Architect. I think this is worng, most likely they are senior developers in java or .net or a architect that knows one of this languages a real architect know more than one language for me. So an Architect is an architect is not an Java Architect. If you just know java could you be consider architect? Today a solution could be using several different technologies and stacks, would a pure vendor/language solution be ideal?
I`m not staying you not need management. As you grown into a complex structure you will need coordination, costs control, and management is need as you get something bigger and complex.
But in order to get it right you need realize when and where you fit management. People talk a lot about scaling agile and i think is funny so little is about engineering. People talk about multiples teams, multiple Product owners, multiple work streams, multiple timezones and cultures but where is the engineering? Deming(The Big mind behind Lean) talk a lot about psychology and the ability to understand systems and they nature. Go Google you will lots of things talking about teams and so little talking about stuff like: Culture, Engineering practices, software architecture(real one, not power points) and principles.
October 20, 2014
So this is the first thing to me, work is about learning if you are not learning you are not working you are just being a machine and belive me a bad one because machines can do better repetitive task them us. There are always a chance to learn something, the problem is that people dont make time to this, instead they are always using the same old tools and approaches. Because is easy an often people feel good to be in the comfort zone, i few awful if i dont learn something new every week actually i got sick.
If you think on abstractions a Service in Service Orientation(SO) it`s a composed by a service implementation and a contract.
A service could implement multiples contracts. I like to have one contract per service but there are scenarios where you could like to have more than one, for service aggregates or domain segregation cases.
So whats is a contract? For SOA contract is DATA, thats the real contract, but this could be seeing as many things, so i like to thing in some things to define what is the contract. SOA is about Design so this could change depending of your main architecture design but in the way that i see it a contract would composed by the following elements.