Thursday, October 8, 2009

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places.

If you're in the habit of pre-announcing your software, then the general public usually wants a timeframe, which implies a date. This is, I think, one of the reasons Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.

The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take. So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google.

Don’t we spend our entire professional careers designing, writing, and testing code? That’s what we do, right? Well, no. What we actually do is deliver business value, or solutions to real-world problems, or however you want to state it. That’s why companies employ software developers. Source code is merely the necessary evil that’s required to create value. With few exceptions, source code itself is not a valuable commodity.

Tradeoffs: the better of two goodshave as little source code as possible vs well-written, maintainable code is often more verbose than dense, impenetrable code, but you should always favor maintainability

Tradeoffs: the lesser of two evils...

False Economiescompanies will happily spend multiple months of an employee’s time, at a true cost of at least $10,000 a month, counting benefits, office space, and the like, in order to avoid paying $1000 or even $500 to license a third-party software package that does the same thing

Monday, July 6, 2009

abstraction is not always a good idea. Web services take the approach of trying to hide many very different technologies under a single abstraction layer — but abstractions tend to leak. For example, there is a huge difference between sending a message via JMS or as an HTTP request. Trying to dumb widely different options down to their least common denominator serves no-one. An analogy would be to create a common abstraction that hides a relational database and a file system under a common API. Of course this is doable, but as soon as you address aspects such as querying, the abstraction turns into a problem.

Finally, as Mark Baker once coined: “Protocol independence is a bug, not a feature”. While this may seem strange at first, you need to consider that true protocol independence is impossible to achieve — you can only decide to depend on a different protocol that may or may not be on a different level. Depending on a widely accepted, officially standardized protocol such as HTTP is not really a problem. This is especially true if it is much more wide-spread and supported than the abstraction that tries to replace it.

Sunday, June 28, 2009

Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him:SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

Saturday, June 27, 2009

"Michael Feathers who wrote a book defining Legacy code as code without tests – hardly a moderate point of view"

Philip Schwarzabout 2 hours later: @Uncle BobYou said: People who excel are, by definition, zealots. People who aren’t zealous, do not excel. I can’t help quoting the following Pattern I read in Software for Your Head:

Greatness is conceived in your intention to achieve at an appropriate scale; it is born in the application of integrity; it flourishes in your navigation of conflict; and it matures in the vitality of your passion.

The GreatnessCycle is an important group behavior cycle. It is simple to understand, but difficult to practice. Its phases are as follows:

1.Smart people are present no matter what they are doing. ...Smart people will exploit the fact that the deeper one’s presence in any given moment, the more valuable the moment.

2.Presence leads to integrity. ...A lack of integrity and the fullness of personal presence are mutually exclusive. That is, a high level of presence is always accompanied by a comparable level of integrity.

3.Integrity leads to conflict. ...Individual integrity doesn’t automatically bind together individuals, but those persons will deal forthrightly with the differences that arise. To do less whether to avoid a conflict, to gloss over it, or to deal with it surreptitiously is to lack integrity. The maintenance of integrity leads to conflict.

4.Conflict leads to passion. If you care enough to weather the direct, honest conflict with your colleagues that flows from your practice of integrity, then you must care a great deal indeed. The emotions you feel when issues you care about are threatened will intensify into passion. Conflict is catalyzed by caring, and summons passion.

5.Passion leads to greatness. Passionate living provides the power to do great things. Though it neither mandates nor guarantees it, passion always attends greatness.

False urgency and complacency can be transformed to true sense of urgency

Change is continuousUrgency increasingly important, change is shifting from episodic to continuous, need to create & sustain sense of urgency, strong sense of urgency is moving from an essential element in big change programs to an essential asset in general

Complacency

Complacency is “feelingof self-satisfaction”

Complacency stems from unconscious emotion that leads to us behaving in certain ways

Complacency is a product of success, real or perceived.

How do the complacent think?

·Never think they are complacent.

·Contend with the status quo.

How do the complacent behave?

·Do not look for opportunities or hazards

·Inward focused

False Sense of Urgency

Driven by anger and anxiety

·Anger due to failed attempts to change or when they think they are blamed for the current difficulties

·Anxiety because people worry for their jobs and career, family etc

Useful questions

Are critical issues delegated to consultants?

Do people have trouble scheduling meetings on important initiatives?

Do meetings end with no decisions about what must happen immediately?

Are discussions too internally-focused?

Do people spend long hours developing presentations, run between meetings and get exhausted?

Do people regularly blame others for problems instead of taking responsibility?

Does passive aggression exists i.e. “Oh was that due today? I wasn’t told”

Specific assignments not completed on time and/or with quality?

True Urgency

·Focuses on critical issues – Not agendas overstuffed with just important or trivial

·Driven by deep determination to win – Not by anxiety about losing

·Try to accomplish something important every day – Never leave 1000 miles in last week of race

·Think that action on critical issues is needed now

·Not “I must have that meeting” but “that meeting must accomplish something important”

·Not belief that all is well or it’s all a mess but world contains great opportunities & hazards

About Me

Software Developer with 17 years experience as senior developer and tech lead in many large and small agile teams. I enjoy consulting with teams to implement improvements in development, testing, and devops practices leading to higher-quality software. I've experienced many of the pros and cons of Agile/Scrum/XP/DevOps and I'm always looking for continuous improvement in both team efficiency and personal skill. I believe the world needs more well-rounded developers, capable of seeing themselves in the bigger picture, able to quickly spot bottlenecks in the delivery pipeline - whether it be in Dev, QA, or Ops - and work with a sense of urgency to fix them with cutting-edge technical ability while using well-honed interpersonal skills to help improve the culture around them. Passionate about giving back to the community, I co-organise the DevOps Brisbane Meetup group and help run study groups for professional software developers on topics such as AWS Solutions Architect Certification, Continuous Delivery, Functional Programming, NoSQL & Distributed Systems, and enjoy inspiring IT professionals to sharpen their craft through professional development and group learning.