Management Anatomy

RSS

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

- Tony Hoare

Simon Sinek about people

"The goal is not just to hire people who need a job, it is to hire people who believe what you believe… If you hire people who believe what you believe, they will work for you with blood, sweat an tears."

The speed of change in the digital economy: Marketing myopia

connected-marketing:

Many companies define themselves almost completely through the product or services they offer. This is a common approach that can seriously narrow the focus. Extensive attention on products rather than customers’ needs, create a “marketing myopia” resulting in business nearsightedness or…

Nothing to add, other than a short note: the original article is a little bit longer, but worths the space for every word.

Building a management team is something you have to do business by business, person by person, day by day. I read their reports. I watched them interact with customers. I sat with them in meetings and evaluated the clarity of their thinking and whether they had the courage of their convictions or were weathervanes ready to shift direction if I scowled or raised an eyebrow. I needed to know they were comfortable discussing their business problems candidly with me.

- by Louis V. Gerstner - Who Says Elephants Can’t Dance? 

A lot of companies have innovation departments, and this is always a sign that something is wrong when you have a VP of innovation or something. Creativity and innovation are something you can’t flowchart out.

-

Apple CEO Tim Cook

One of the major difficulties regarding innovation is that it’s often confused with strategy. That’s a huge mistake.

  • Strategy is a high level function, which concerns the overall direction of the company and therefore necessitates considerable involvement of senior management as well as, at times, high-priced consultants.  The outcome is a plan that puts relative strength against relative weakness or opportunity.
  • Innovation has nothing to do with overall direction.  It involves building a portfolio and hedging bets.  You go into it knowing that most of what you do won’t work out.  You continually fail, dust yourself off, pick yourself up and try again.  Keep at it and you will succeed eventually.  Innovation is a big word, but it’s a dirty, messy business. 
(via connected-marketing)

I learned that whatever hard or painful things you have to do, do them quickly and make sure everyone knows what you are doing and why.

- by Louis V. Gerstner (Who Says Elephants Can’t Dance?)

European software producers place more attention on achieving elegance in software design than on shipping products for mass markets and making the most money they can from their excellent technical skills.

-  by Michael A. Cusumano (The Business of Software )

Good features and ideas that do not integrate with a system’s basic concepts are best left out.

- by Frederick P. Brooks (The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) )

1993, a prominent U.S. consultancy discovered that 44 percent of all bugs start before the coding even begins.

- by Edward Hasted (Software That Sells: A Practical Guide to Developing and Marketing Your Software Project)

Complexity is, by definition, complex.

- by Edward Hasted (Software That Sells: A Practical Guide to Developing and Marketing Your Software Project )

YAT: Convention over Configuration (and Documentation)

Are you seeking for more efficiency in the software development process? is your target also to do more with less. Here’s a YAT (Yet Another Technique), to reduce cost dumped in the process. 

Let me take you in a short introductory trip before:

Recently I’ve started to learn German language. The basic concept of conjugation of the verbs is simple. Let’s take the verb spielen (playing) as an example:

Ich spiele (I’m playing)

Du spielst (You’re playing)

Er/sie/es spielt (He/She is playing)

So, you can draw the simple conclusion - you take the root of the verb (spiel) and you follow some sample rules, like: in 1st person you add the -e as termination, in the 2d person you need the -st termination, while in 3rd person you will add the -t termination.

Like this, you could continue with another verb: arbeiten (working). So:

Ich arbeite

Du arbeitest

Er/sie/es arbeitst

Simple enough? see, we are one step closer to speak German :) But wait a minute… let’s use our new knowledge and take the verb “dürfen” (may - to be free to do something):

Ich dürfe, Du dürfst, Er/sie/es dürft?!? - the answer is: no. Unfortunately this is an irregular verb, so the rule listed above doesn’t apply here. Here how you are conjugating:

Ich darf

Du darfst

Er/sie/es darf

:( - nothing to do with the knowledge we collected before. So what rule applies to the irregular verbs… none: that’s why they’re called irregular (there’s no common convention what to do with them). 

So what I can do with the conjugation of irregular verbs as a beginner of German language? Nothing more, than learn all of them by hard.

So my learning process will be extended and longer that I expected? The answer is yes!

The same applies for software system which is reinventing its own rules for each and every module… one can not learn a rule and apply it in multiple places (multiple modules of the system), but needs to learn the specific aspects of all parts.

I’ll give you a few open questions:

  • how much additional unit testing you need for non-standard components?
  • how much more you need to do documentation for non-standard components?
  • what is the additional operational work (configuration, training and issue handling) because of no convention and standardization is applied?

expense-to-revenue ratio—i.e., how much expense is required to produce a dollar of revenue—was wildly out of range with those of our competitors. On average, our competitors were spending 31 cents to produce $1 of revenue, while we were spending 42 cents for the same end. When we multiplied this inefficiency times the total revenue of the company, we discovered that we had a $7 billion expense problem!

- Yet another superb KPI from Louis V. Gerstner (Who Says Elephants Can’t Dance? )

Still the one

stepwise:

Even the best strategy means nothing if it’s not implemented well: Apple didn’t failed in this regard.

CPV as the main guideline to your product design process

Customer Perceived Value is a term used in marketing, which describes a simple concept: the value of a product for us (as a customer) is calculated according to the formula

Value = Benefits / Cost.

In order to design a successful product you’d increase the benefits and reduce the costs.

Simple enough you’d say… but let’s look on the components.

Costs: what are the costs? the price of the product? what if it’s free? or what if users do choose the competitor despite the fact we are cheaper?

Costs consists of multiple elements: yes, there’s a monetary costs (how much I need to pay for), but there’s also a time cost (how much time I need to invest to acquire or how), energy cost (how much do I need to invest in learning), psychic cost (how simple is to use).

Benefits: product value (which of my problem solves the product), service value (how happy I am with the customer support), image value (how do I look in the eyes of my peers if I am using this product).

More on this topic: http://www.marketing91.com/customer-perceived-value-cpv/

Software QA starts with the product design

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest (Lean Software Development).

Half of the software development efforts (and budgets) are consumed by quality assurance (QA) processes (unit testing, system testing and acceptance testing). One third of the development is about planning and only one sixth is about actual implementation (coding).

In other words: while the creative process takes about the half of the time, the other half is about sorting out the mistakes from this initial effort. That’s why is important to recognize, that quality assurance starts at the planning phase. If the software architecture is lean and clean it will probably be cheap to maintain.

So how to make it lean and clean?

Ubiquitous domain language is one way to proceed. Does it sounds like a hype expression? for sure. Let me simplify: use simple, straightforward terms, do not let to proceed with a concept which is not understood by every team member in the first 10 seconds. (Remember? every 10 % of complexity in the domain model adds 100% complexity in the overall development process).

Teach your team about TCO (Total Cost Of Ownership): show them what’s the cost of maintenance. Help them to adopt KISS.

Adopt agile methods: re-factoring for keeping simplicity, clarity, minimum amount of features in the code.

Or in other words: “Think big, act small, fail fast; learn rapidly" – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process.

Use conventions over configuration: this is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.