Over the last few weeks I have been reflecting on the different types of organizational cultures I have been part of, and how these organizations approach leadership. As I have gained experience of the good and the bad, also made mistakes of my own, I believe there are two foundations to leadership that need to be constantly cultivated – Trust & Respect. Through understanding of what leads to trust and respect in an organization is to me mindful leadership. 

Trust and Respect have their own characteristics but in terms of leadership they are bidirectional, leaders need to trust and respect their teams and teams need to trust and respect their leaders. If either of these is lost an organization will sink into major dysfunction and lose its ability to be successful. As a leader you have to nurture trust and respect, this is sometimes done through actions and not through demanding or dictatorial behavior. Sometimes it is actions that in some organizational cultures would be seen as weakness in leadership.

For example, when forming a new team you will inevitable have gaps and mistakes in the team’s performance as they form. Criticizing this through reprimands, particularly publicly, will significantly reduce the ability for a team to form and trust the leadership. This leadership approach will result in the team becoming defensive or worse look to leadership to make all their choices, to avoid future reprimands. In certain organizational cultures the approach of not reprimanding for mistakes, but quietly coaching improvement is seen as mismanagement by a leader.

For me successful leadership is when you bring people together, form them into a team and head off on a mission, where there is mutual trust and respect between leadership, teams and individuals. Successful leadership is measured in the engagement and happiness of your teams, because when this is achieved organizations produce the greatest products/services and everyone whats to be part of it. Organizations with fully engaged people out perform those who do not by 200%.

For me I would summarize my approach as the following:

• Treat people as people not human resources, not just an employee number on management report.
• Look at teams as heterogeneous groups of people not homogeneous, you need different ingredients to make a cake.
• Missions have clear objectives and success criteria, not some word-smithed marketing phrase.

Ok so these are pretty simple to say and maybe pretty obvious, however to build successful teams and organizations you need to deeply understanding each. This to me is mindful leadership.

Let me try and highlight this deep understanding with a few examples:

Do you see examples of things that affect trust and respect?

The post Trust and Respect – Mindful Leadership appeared first on daVinci Rocks.

Leonardo da Vinci’s codex are probably some of the most famous notebooks in existence, even just the few that still exist are seen almost as works of art and fascinate many people myself included, it is believed that there were many more destroyed. They are simply his records of discovery, development and observation on a wide range of subjects.  Most engineers, inventor, academics, scientists and innovators overtime have keep notebooks of their ideas and findings on the good and not so good paths of discovery they have taken.

There in my view some essential aspects of a notebook that are not immediately recognized by people, this is the freeform nature of anyones notebook. It is used exactly as the owner wishes not defined by some external prescribed approach, you can scribble in margins, overlay thoughts on one another and the order is not hardwired in any way. To me I have come to realize it is a representation of the way I think. As we all think in a somewhat unique way it is essential that the notebook is freeform to capture that.

I have always kept notebooks full of the systems, designs, architectures and code patterns I come across or use in my profession, this comes from my early years in electronics. At this time engineers would routinely keep notebooks of their designs and calculations, I find this practice to be more than a tool to remember details but also as an aid to understanding the principles involved – if you write something in your own terms it has a greater tendency to be understood and absorbed.

In this project I am looking to to see if there are new ways to synthesis the traditional notebook, make it better by using the emerging technology of tablets such as the iPad.  My notebooks overtime end up in books stored away, what a waste- surely today there is a way to have them all perpetually at your finger tips. Even share them with others.

However one of the key aspects in this project will be to keep the fundamental essence of a good notebook:

1. It is YOUR notebook and freeform to accept your thoughts.

2. You can scribble in the margins.

3. You can reference books and other materials

4. You can stick copies of examples or reference patterns (calculations, design patterns, etc).

5. You can draw your own diagrams and annotate.

6. It is left organised the way you think not the way a DB is structured.

As a testbed for this I have decided to write a serious of articles on SaaS Engineering using my notebooks (see “SaaS Engineers Notebook“) and see what would the practical way to design a tool for this purpose.

The post Engineers Notebook Project appeared first on daVinci Rocks.

Now I am onto the next none programming project, building a 1917 Sopwith Camel Fighter at 1:16 scale the SF Cable car was a little to easy. The first stage was putting together the Clerget Rotary engine.

There are a few interesting things about this design and the implications it causes, the engine operates by rotating around a fixed crankshaft. This is not normal for today’s engines to say the least, if you look at the scale model example I built in the picture here, the propeller turns along with the whole engine and the central crankshaft is fixed. This has the benefit of improving cooling of the nine cylinders which was a problem for engines of the time, however it meant that oil used to lubricate the internals of the engine was thrown outward because of centrifugal force and would leak out of the valve/rocker assembles on top of each cylinder.

To overcome this issue they engine needed a constant supply of oil delivered with the fuel mixture, in comes castor oil the only oil of the time that was no soluble in petroleum fuel.

However as with most developments in the early stages this actually moved the problem to another location, the pilot. Castor oil has the wonderful property when administer to people of being a laxative, so imagine the effects of being behind an engine that just keeps on spewing out castor oil (burnt and unburnt).

The first line of defense is a silk scarf to wipe it from you face and goggles (you thought the dashing white scarf of the men in flying machines was for style!). However for the medicinal effects of caster oil the pilots would carry flask of Blackberry Brandy to stop things from loosening up to much.

Although it is debatable if the cowling over the engine was put there for aerodynamics or to divert oil away from the pilot and under the aircraft.

This a video of a Sopwith Pup the predessor of the Camel but they had the same issue with the rotary engines, if you listen to the commentary you will hear details on how they needed to prime the engines to start, etc.

Sopwith Camel Engine Start

The post WW1 Rotary Aircraft Engines lead to Brandy and Silk Scarfs for pilots appeared first on daVinci Rocks.

This model San Francisco Cable Car was from a OcCre kit and is 1:24 scale. Fairly simple to put together, about the only painful bit during construction were the windows. First the window frames, to which the clear Styrene is attached, did not match the cutouts in the main body of the cable car. The frames we significantly small, which seemed to have been caused by the laser cutting of the wood basically being to high (excessive burning marks could be seen on the sheets). I would recommend inspecting this before buying if you can as I had to build shims to reduce the size of the window cutout and then file and trim everyone individually.

The second problem with the windows was the effect of using CA Glue (Cyanoacrylate) in the model, first don’t use it to affix the Styrene to the wooden window frames, use a specific glue for ‘clear parts’ like Testors Clear Parts glue or to will get very messed up windows. The next thing is clean the windows after putting them in place otherwise if you leave grease from your finder on themand start constructing the rest of the model with CA Glue you get what I am calling the ‘Criminal Forensics’ effect – your finger prints will start appearing from even the small amounts of fumes.

For interesting information about Cable Cars and how they work checkout these sites:

http://en.wikipedia.org/wiki/San_Francisco_cable_car_system

http://www.cablecarmuseum.org/mechanical.html

The post Building a 1:24 scale model of a San Francisco Cable Car appeared first on daVinci Rocks.

Firstly this book is a great reference book and is filled with very valuable examples that will save you loads of time in your next application. However it is not for someone who wants to learn Objective-C or how to write a iPhone App, if you want to learn that check-out something like Learning iPhone Programming by Alasdair Allan this will get you the basics of iPhone App construction.

However back to this book, it will rapidly shorten your learning curve in some of the more complex areas and give you valuable examples to extend the more run of the mill parts of iOS. It starts by covering some of the basics like Working with Objects, Implementing Controllers and Views also Table Views,  as mentioned these are not tutorial level descriptions and you need to understand the basics of an iOS application structure (iOS MVC pattern implementation, delegates, outlets, etc.) before heading here – “there be dragons”. The real meat starts with Core Locations and goes through Gestures recognition, networking, threads, etc. one of the fundamental shifts with the iPhone and iPad is the user interaction through gestures worth spending time here. Also networking with a mobile device however smart is difficult, this book gives great examples of downloading and cacheing XML files.

The pinnacle of the book however in my view is the treatment of Multitasking, Core Data, Graphics and Core motion these make the book more than worthwhile and a must have for any serious iPhone/iPad developer.

In summary a great reference book for the mid to advanced level developer.

Available at O’Reilly at

Or Amazon at

The post Book Review: iOS 4 Programming Cookbook by Vandad Nahavandipoor appeared first on daVinci Rocks.

In one of my previous blog articles I talked about Software Debt escalating to Technical Bankruptcy, here I will explore more the need for and apparent lack of monitoring of accrued software debt within businesses. The lack of understanding of software debt by business managers, particularly those based on software as their primary product, is a fatal mistake in their business strategy in my view. It is akin to only looking at the sales numbers and not a the operating expense, one day you’ll find yourself paying more for a sale than the revenue from the sale.Recently I used the idiom ‘the straw that broke the camel’s back’  to convey this point, I particularly liked it as the original Arabic proverb describes how a camel is loaded beyond its capacity to move, that is exactly what happens with software debt the organization gets to the point that it cannot move forward. The basis of the analogy I used to convey the impact to software production was that the straw on the camels back was composed of :

1. Software Architecture that was pushed beyond its original intent.
   • New architectural approaches partially implemented, tactical features always took precedence.
   • Multiple partially implemented architectures, etc.
2. Poor development practices
   • giving up Unit Tests for speed of delivery
   • inconsistent application of code and design reviews, etc.
3. Poor product management decisions
   • only looking for the customer facing UI components and ignoring the back-end implications. Great blog on this behavior here.
   • never prioritizing technical debt over features, etc.
4. Poor Operational and Deployment practices
   • No Continuous Integration, No common build system, etc.
   • No standard configurations, manual deployment at all levels of the system.

You probably get the picture, I left out a lot of the specifics above,  and for the business management I kept it to the four headlines above. It got the point across to them and we immediately started to look at ways to deal with the issues. The temptation to revert to prior behavior was always present and the question of ‘are we there yet’ kept on coming up and this is the fundamental problem, believing that Software debt will disappear is a complete fallacy, it is always present and takes constant management to stop it from getting out of control. So it is imperative in my view to manage it from the beginning and if that time has already passed then from this point forward, pretending it is not there is like not opening the credit card statement each month. There are indications that this is becoming more central to business discussions, great post here, however it seems that Agile approaches are placed central to it, I have to say Agile is making it visible and by no means is Software Debt limited to these organizations. So how should we manage Software Debt and make sure it is visible to the Business Management. First is to communicate and educate business management on software debt, it is not taught in MBAs or in business school so few a likely to even understand the phrase let alone the details. Secondly keep it simple, I see all of the types of issues in software debt as defects, yes they need to be categorized into useful groups so that a plan of action can be created to tackle them, but they are all defects of one sort or another. The defect may appear due to changes in desired use, they may just be there because we took a short cut and now it is time to move into the full solution, any number of reasons. My belief is that Software Debt should be accounted for and used as a business management metric the same as feature delivery against market goals are measured. If you are going to spend the time within Product Management and Product Ownership in calculating the ROI for features, simplified here as:

Potential Sales over x period / cost to produce(Investment) = ROI

Then you should also calculate your current software debt burden and what the new feature will add to it:

(Number of defects existing + Projected Number of Defects with new feature) * Average cost to fix = Software Debt Value

(Yes these numbers can be subjective and so are the numbers for the normal ROI calculation used by Product Owners for features. For those of use with the Meyers-Briggs NT profiles we need to get over it, by the time you have hard numbers scientifically proven it will be too late the business will have moved on. Leave you with a pile of Software debt needing to be dealt with.)

The post Software Debt – Do you know the health of your ‘Camel”? appeared first on daVinci Rocks.

It was a fascinating process building this model, the designers of the model held true to almost all of the original design of the Wright Brothers. As I progressed through the building of the model I would compare it to the photo graphs and the literature available, this is why I say the designers appear to have held true.

One of the great things that appealed to me about the Model Airways kits was that they left visible the entire construction of the plane. This does present that issue that all my flaws of construction are also visible, so if you decide to take this kind of model on spend time reading the instructions, they are pretty good, and I found that tacking together the pieces before final gluing was very helpful to ensure that correct alignment is achieved. Basically try it before final commit. When doing the rigging I would learned the hard way that you should tie off all of the rigging before putting a little bit of glue on the ends (then you can trim excess), if you glue as you go you will find the next following pieces of rigging to be more difficult.

In my previous blog about wing wapping I explored the innovative way the Wright Brothers choose to control the aircraft.

All in a great model building experience, I intend to tackle some of the other models from Model Airways, the one piece I could think of adding (and I may do this) would be a partial wing covering maybe for one wing tip. The reason I say this is that the cotton wing covering the Wright Brothers used and the way in which is was put on was quite fascinating. These really are museum quality models, although I don’t think my final build was to this standard, they will take time an focus to build correctly but very very rewarding.

I found the book “Wright Brothers and the Invention of the Aerial Age” by Peter L. Jakab &  Tom D. Crouch a great read and I learned a lot about the Wright Brothers I was unaware of before.

The post Building a scale model of 1903 Kitty Hawk Flyer appeared first on daVinci Rocks.

NYU Professor Robert Faludi, has supplied a very easy to follow book tackling the construction of a XBee wireless network, which is not as simple as it may appear. He provides both a step by step guide and a basic understanding/education of the technology involved.

This book starts with describing initial choices around hardware and software to construct a XBee wireless network, Professor Faludi also does a quick tutorial on radio transmissions theory and wireless networking. Once you have the bits and pieces set out, Professor Faludi walks through a number of projects helping to build up the readers overall knowledge:

1. A Wireless doorbell

2. Romantic Lighting Sensor

3. Simple Sensor Network

4. Simple Sensor with Sleep Project

He then discusses a XBee Internet Gateway (XIG) project ( see his blog), this opens up the borders by allowing the XBee radios to proxy through the ConnectPort X2 and hence be accessable via the Web.

Next project, a project to Tweat to a XBee. Professor Faludi concludes the book with a review of the ZigBee stack, a list of plans for the ZigBee platform. Finally there is a resource guide for Arduino, Python, ZigBee, Digi, etc.

This book really offers a end to end introduction to XBee radio networks and is well worth the time for anyone who is hacking or looking at industrial applications in sensor networks.

Available at O’Reilly at

Or Amazon at

The post Book Review: Building Wireless Sensor Networks by Robert Faludi appeared first on daVinci Rocks.

David  Knootz commented on my recent post about Technical Bankruptcy referring to an interesting thought in his blog “Technical Debit – Collateralized Debt Obligation you should not invest in.” I was just going to reply to his comment but my response got more and more involved :-).

The CDO comparison presents a interesting thought, for me a follow-on question to David’s posting would be are some organizations already making money off of Collateralized Technical Debt – it is less expensive in the short term to miss out that finicky automated testing and unit testing stuff – unmanaged outsourcing, consultants, etc. or organizations that just spend too little time on managing technical debt.

Technical debt will happen, I would say if you have removed all debt from your code before releasing it then you have spent to much time perfecting it and highly likely missed any market opportunity that existed. Technical debt becomes bad when it is hidden and forgotten about, it is like having a mortgage and only paying it if you feel like it or never; bad things will happen.

As with CDOs the idea of hiding small pieces of Technical Debt in a larger body of good code holds true, the problem is – here is my Warren Buffet moment – the bad technical debt can cause the entire body of code to loss credibility. The “one bad apple can ruin the whole barrel” metaphor, unmanaged technical debt can lead to the entire system being viewed as unstable. This loss of confidence, usually by customers, can lead to the failure of the venture.

Thanks David and I hope I have captured or extended some of your thoughts.

The post Collateralized Technical Debt compared with CDOs appeared first on daVinci Rocks.

Software Debt goes back to the very beginning of development but the metaphor was first voiced by Ward Cunningham when he compared technical complexity and debt in a 1992 experience report:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

Now what happens when the debt load gets so great that the organization is brought to a stand-still, as referenced by Ward Cunningham?

I believe we need to extend the use of the same metaphor from the financial sector and analyze technical debt first from a numbers point of view before diving into the technical problem solving. In finance an organization is regularly audited to ensure that its records are accurate, part of an auditor’s job is to determine and comment on whether the organization is a ‘going concern‘ generally if an organization goes into bankruptcy in between audits and a comment on whether the organization is a going concern has been incorrectly stated, the auditor is first to be sued by those using the auditor’s report (investors, etc.). The statement is based on whether the business can continue without going into liquidation for a period, usually 12 months.

Do you have a ‘Technical going concern’?

In the case of technical debt I believe management should also look to see if they have a technical going concern and if there is risk of technical bankruptcy. To ascertain the health of a software product the first step is to audit the product development group in terms of the following, for each category producing the effort needed (equivalent to the financial budget for each):

1. Open defects that are real for customers. This should be audited in terms of total number, and estimated time to close. The key is turning this into a value that can be used in the final audit analysis. First the defects need to be ordered in terms of criticality (the priority in which they need to be fixed for the customer) and count all that are hindering the customer in the use of the product (anything that is none cosmetic).  Then estimate time & resources needed to solve the issues and get it to the customer. This could either be estimated person-hours for defects. You should end up with a figure that represents the effort needed against time.
2. Engineering Practice issues that are impacting your release cycle, getting the product to customers. Identify issues that repeatedly cause lost time, order them by the resulting value of ‘occurrence per release cycle’ multiplied by the ‘total person-hours wasted for each occurrence’.   Choose a point such as anything of 6 person-hours (a good value for 1 person-day) also eliminate any that can be fixed in less time/cost than they absorb, as this should be a no brainer. Again use this final list to give you a figure that represents the effort needed against time. For a SaaS/Web operation the issues would be like those here (similar issues apply to box product release also):
   • Build failures
   • Regression failures
   • Server configuration issues
   • Data structure issues
   • Post release issues that were not caught in testing
   • Any pattern based failure that repeats

These two values should be represented in terms of the resources needed over 1 year and in terms of each quarter, this is generally how all businesses operate and product development should fit into that cycle. For example:



Then as shown the investment needed to implement features, this provides the ability to balance the books against the capacity of the teams available. Now there are all the details of skill sets, not subdividing teams, etc. however this is an exercise in determining high level feasibility; in practice I have produced much more complex models to valid the effort needed. However, in my experience if you are already in the red or just barely in the black at this level there are significant issues and you are looking at the organization not being a technical going concern.

In the last year I have come to like Chris Sterling’s definitions of  ‘software debt’ and would broaden the calculation of effort to these categories, I have added my view of the way to quantify this from an audit perspective:

1. Technical Debt: those things that you choose not to do now and will impede future development if left undone
   • Captured as the effort needed to stop compounding the debt, also the effort needed to deal with customer defects as stated above.
2. Quality Debt: diminishing ability to verify functional and technical quality of entire system
   • Capture as the effort needed to develop and implement a sustainable test harness.
3. Configuration Management Debt: integration and release management become more risky, complex, and error-prone
   • Capture as the effort wasted on each release cycle through configuration errors. Also the effort it would take to fix these issues.
4. Design Debt: cost of adding average sized features is increasing to more than writing from scratch
   • Capture as the effort needed to redesign parts of the system where new or enhanced functionality is not being delivered. ie. When it cannot be classified in the new feature bucket. This can be difficult as you would be looking to always deliver customer benefit, but we all know it when we see it you just have to be honest with the attribution of effort.
5. Platform Experience Debt: availability and cost of people to work on system features are becoming limited
   • Captured as the cost of replacing those key holders of knowledge when you have the risk of becoming single threaded. This one is event driven so should be categorized as risk and used in ‘what-if’ scenarios.

Are you in technical bankruptcy or heading there?

Step two is to determine if you product is heading to technical bankruptcy and if you can do anything about it. For me, the gauge of this is can you effectively tackle the Technical debt in a 6 month period so that it absorbs less than 50% of your overall resources and then be able to sustain a trajectory to reach 20-30% of your overal resources within 1 year. If you cannot do this you are heading to technical bankruptcy or are already in it in my view.

If you are, or can get to being,  a technical going concern then maintaining a simple audit approach through what should be standard metrics of a development organization is a useful management practices to watch as any CEO or CFO would watch his balance sheet.

If you are technically bankrupt what are the options?

For me you have two options:

1. Technical Restructuring – force the 70/30 split with 70% of your resource going to build a new structure. Again you need to be doing this within 12 months. Getting close to 12 months or going over is rarely successful. During the restructuring enlist the rest of the organization to manage the inevitable heat from your customers, this kind of undertaking is not a technical endeavor it is a business endeavor and needs the support of everyone involved in the business. Part of the restructuring may require gaining additional outside capital for the investment, these kinds of efforts are not normally cheap.
2. Limp along until customers flee your product for competitors, during which time the management of technical debt will become the entire focus of the organization with ever-decreasing market differentiation.

Basically once you are approaching, or in technical bankruptcy,  just as with financial bankruptcy you only have expensive and high risk options available to you, so it’s better not going there…..pay attention to technical debt and audit against it regularly.

The post More than Software Debt….Technical Bankruptcy appeared first on daVinci Rocks.