I have been contacted by the people at crossover.com offering me a "fantastic" opportunity...
Yeap, the figures were nice indeed, but then I started to think deeper on what they are offering.
The punchline was "With us, going to the office is history!"
I love going to the office, I love the long strolls and the autumn leaves on the walkway. I love talking to people and learning with them. Why would I spend the entire day home? Would I be more productive? Will I be more technical? I doubt it? Will I produce something meaningful?
One thing is for sure - I will get more and more intolerant and egoistic. I will start fearing my virtual job as I have no direct connection with the true project. I'd be an executor in a big BPMN diagram... Do I really want this? It would be at least heartless... And I am not an robot.
The second thing is that I am holding a grudge to someone... Not a big one... But he somehow lied me twice. And that someone is now a VP in this company. With this being discovered my final decision is a heartily: "No, thank you!"
PS: I have discussed a couple of days with some guys that were admiring the VP because he has now money. Lots of them. They were considering that he does a good deed "employing" people. Then I am wondering why none of his henchmen went together with him in this "endeavour"...
Monday, November 9, 2015
Monday, October 26, 2015
Architecture compromise budget
I have been involved lately in more than enough architecture discussions. Microservices, REST, messages, asynchronicity and all the rest... Everything looks good in theory but when it comes to finalization we hit the wall in full speed.
Here the compromise starts creeping in. Developers cut corners, business demands features, the UX should be improved. Most of these come with an architectural cost. This cost should be more or less converted into a "architectural debt". In order to work with this I decided that I have an "compromise budget" that is consumed by the architectural debt.
What I did was to quantify the architectural debt based on a simple formula:
From where the formula? Well it is kind of empirical curve fitting on the projects I have worked on:
1. Data model influences most of the coding due to the fact that changes in the model might influence all other tiers of the architecture. So the impact is quadratic to the change.
2. UI cost influences the presentation layer and the impact is quite linear - as far as I have seen.
3. The logic cost is in linear relation with the change size. Although it seems quite odd in fact the change is localised in the business logic tier so it might justify the relation.
4. Testing is important as the architecture changes so everything has to be double checked with the specs and regressions have to be mitigated.
5. Communication cost is by far the most important one as the architect has to be a jack of all trades and sit at the table with many stakeholders each one with its set of driving forces.
The formula is non-dimensional so the variables have to be described consistently (money, man-hours, ...) in the end it will all converge to money as this is in fact just a technical debt.
So how I used it? For example I have set a Compromise Budget of 150 units on a project and started to do the math:
1. Devs using synchronous calls instead of async: after the evaluation I have obtained a cost of about 20
2. Data model changed due to multitenancy, feature added late: about 80
3. Late decision on third parties used: around 20
So far I used 120 units of my 150 budget. In the moment that I get a new request that changes again the data model the formula puts another 45 on the table. So I will have a debt of 15... Is my initial project still inline with the initial idea? Do we build the same product anymore? What to do now?
1st thing is to inform the stakeholders about this. In an agile way we could adjust the backlog and find the best sequence that maximizes the team output in the next sprints.
One important aspect of this is why in fact I accept compromises? Well there is no pure black and white situation so I learned that I have to sacrifice the architecture in order to get things done and have something to deliver. The formula is just a trigger that stops me on accepting more unconformities.
For waterfall this is quite inline with the concept.
For agile, as the role of architect is not well defined, it is mostly an informative KPI that shows the divergence trend between the initial architecture and the current one.
In the end is this budget helpful? For me it is as I use this as an early warning system that enables me to create a strategy for steering the development further on.
Here the compromise starts creeping in. Developers cut corners, business demands features, the UX should be improved. Most of these come with an architectural cost. This cost should be more or less converted into a "architectural debt". In order to work with this I decided that I have an "compromise budget" that is consumed by the architectural debt.
What I did was to quantify the architectural debt based on a simple formula:
debt = 1.3 * data model^2 + 1.7 * ui cost + logic_cost + 2 * testing cost + 1.4 * communication cost ^2
From where the formula? Well it is kind of empirical curve fitting on the projects I have worked on:
1. Data model influences most of the coding due to the fact that changes in the model might influence all other tiers of the architecture. So the impact is quadratic to the change.
2. UI cost influences the presentation layer and the impact is quite linear - as far as I have seen.
3. The logic cost is in linear relation with the change size. Although it seems quite odd in fact the change is localised in the business logic tier so it might justify the relation.
4. Testing is important as the architecture changes so everything has to be double checked with the specs and regressions have to be mitigated.
5. Communication cost is by far the most important one as the architect has to be a jack of all trades and sit at the table with many stakeholders each one with its set of driving forces.
The formula is non-dimensional so the variables have to be described consistently (money, man-hours, ...) in the end it will all converge to money as this is in fact just a technical debt.
So how I used it? For example I have set a Compromise Budget of 150 units on a project and started to do the math:
1. Devs using synchronous calls instead of async: after the evaluation I have obtained a cost of about 20
2. Data model changed due to multitenancy, feature added late: about 80
3. Late decision on third parties used: around 20
So far I used 120 units of my 150 budget. In the moment that I get a new request that changes again the data model the formula puts another 45 on the table. So I will have a debt of 15... Is my initial project still inline with the initial idea? Do we build the same product anymore? What to do now?
1st thing is to inform the stakeholders about this. In an agile way we could adjust the backlog and find the best sequence that maximizes the team output in the next sprints.
One important aspect of this is why in fact I accept compromises? Well there is no pure black and white situation so I learned that I have to sacrifice the architecture in order to get things done and have something to deliver. The formula is just a trigger that stops me on accepting more unconformities.
For waterfall this is quite inline with the concept.
For agile, as the role of architect is not well defined, it is mostly an informative KPI that shows the divergence trend between the initial architecture and the current one.
In the end is this budget helpful? For me it is as I use this as an early warning system that enables me to create a strategy for steering the development further on.
Sunday, June 28, 2015
Metaphors
I watched "Ex Machina" this weekend and I enjoyed the metaphorical construction of the film.
There development is cleverly constructed and there are subtle references to many myths and other SF works. The scenery is breathtaking also.
Also the easter egg in the movie is nice: http://moviecode.tumblr.com/post/119171520870/in-the-movie-ex-machina-which-is-really-great
There development is cleverly constructed and there are subtle references to many myths and other SF works. The scenery is breathtaking also.
 |
| http://www.vanityfair.com/hollywood/2015/04/ex-machina-location |
Thursday, June 18, 2015
Sysadmin work
In the last weeks I have been tinkering around with some sysadmin tools. I had to build a highly available L7 router/load balancer.
I haven't touched the sysadmin hat for more than three year now so I had to sync with the latest technologies. Here are my findings and musings:
1. Operating systems: I had to choose between various Linux distributions. In the end I went with Centos 7. It was close to choose Ubuntu 14.04 but in the end I leaned to Centos due to systemd. I had to get rid of firewalld and use plain old netfilter for my purpose. The drawbacks in Centos are that it not always have the latest packages in epel and that the interface names are somehow unpredictable hence making it difficult to configure them from kickstart.
2. L7 load balancer: I had to choose between NginX and HAProxy. NginX is extremely powerful but I had no previous experience with it I opted for HAProxy. This was also in part due to the fact that it also has TCP mode. However I am still in doubt if I will keep HAProxy because I had also to install some other webserver (lighttpd) along with it. It might have been simpler for me to have just NginX....
3. Some keepalive/watchdog solution. Here I did little research. I wanted a low level solution so I had to choose between vrrpd and keepalived. I went with keepalived and it was fairly easy to use it.
4. IPS - I had to test various solutions but I settled with Snort + fail2ban.
5. DevOps: I had no prior experience with DevOps tools so I have studied lots of them. I read about Chef, Puppet, Salt, Ansible and CFEngine. I ruled out Chef and Puppet as they were too heavy for my setup. CFengine was ok but I did not wanted a server for it. Salt was speedy indeed but I was afraid that its 0MQ transport will not be always carried by proxies. The final solution was in this case Ansible as it works masterless and is based on SSH - making it virtually ubiquous.
After putting everything together I had a nice working system that I stressed a bit and it performed more than fair. It was for me a nice experience - I have especially enjoyed working with Ansible - a very clean and lean solution.
I haven't touched the sysadmin hat for more than three year now so I had to sync with the latest technologies. Here are my findings and musings:
1. Operating systems: I had to choose between various Linux distributions. In the end I went with Centos 7. It was close to choose Ubuntu 14.04 but in the end I leaned to Centos due to systemd. I had to get rid of firewalld and use plain old netfilter for my purpose. The drawbacks in Centos are that it not always have the latest packages in epel and that the interface names are somehow unpredictable hence making it difficult to configure them from kickstart.
2. L7 load balancer: I had to choose between NginX and HAProxy. NginX is extremely powerful but I had no previous experience with it I opted for HAProxy. This was also in part due to the fact that it also has TCP mode. However I am still in doubt if I will keep HAProxy because I had also to install some other webserver (lighttpd) along with it. It might have been simpler for me to have just NginX....
3. Some keepalive/watchdog solution. Here I did little research. I wanted a low level solution so I had to choose between vrrpd and keepalived. I went with keepalived and it was fairly easy to use it.
4. IPS - I had to test various solutions but I settled with Snort + fail2ban.
5. DevOps: I had no prior experience with DevOps tools so I have studied lots of them. I read about Chef, Puppet, Salt, Ansible and CFEngine. I ruled out Chef and Puppet as they were too heavy for my setup. CFengine was ok but I did not wanted a server for it. Salt was speedy indeed but I was afraid that its 0MQ transport will not be always carried by proxies. The final solution was in this case Ansible as it works masterless and is based on SSH - making it virtually ubiquous.
After putting everything together I had a nice working system that I stressed a bit and it performed more than fair. It was for me a nice experience - I have especially enjoyed working with Ansible - a very clean and lean solution.
Sunday, May 17, 2015
Shipping News
As the character in the book/movie I sometimes have to write something...
I have lately worked on some doves tooling using Ansible. I had my share of frustration with Chef lately due to the fact that I wanted to use it with windows clients. For Unices Ansible works ok. In my opinion its playbook are simpler to understand/manage than Chef's recipes.
On the other hand I am also experimenting with HA solutions (HAproxy, keepalived). So far so good.
I have lately worked on some doves tooling using Ansible. I had my share of frustration with Chef lately due to the fact that I wanted to use it with windows clients. For Unices Ansible works ok. In my opinion its playbook are simpler to understand/manage than Chef's recipes.
On the other hand I am also experimenting with HA solutions (HAproxy, keepalived). So far so good.
Sunday, April 26, 2015
Wonderful hardware
Due to chickenpox I bought a Wii console.
I couldn't resist it and I soft-modded it (letterbomb).
I played a couple of days all kind of games together with my doughter (Sports, Party) and some just myself (Dead Space and Quake). I am impressed how well these games work on the weak hardware the console has (at least to nowadays standards). What it does on 64MBytes RAM and on a processor running at 729MHz is amazing.
All in all I have a new collectible in my odd/vintage hardware collection that now contains a Sparcstation Classc, a SGI, a Mac Cube and a Sun Ray. I am really into buying an old HC/Spectrum...
Subscribe to:
Posts (Atom)