Tag Archives: of

Jacob Gube: 6 Ways to Increase the Visual Weight of Something

Readers:

Jason GubeWhile purusing through Zite, I came across this blog post on the Design Instruct web site by Jacob Gube. Jacob is the co-founder and a managing editor of Design Instruct. He’s a web developer, and also the owner of Six Revisions. Follow Jacob on Twitter: @sixrevisions.

Best Regards,

Michael

6 Ways to Increase the Visual Weight of Something

In a design composition, the visual weight of an object refers to how well it draws attention to itself compared to other components of the composition. The “heavier” the object is, the more eye-grabbing it is.

When creating a design, it’s a good idea to prioritize key elements in the visual space by giving them heavier visual weights. For example, things you might consider giving heavier visual weights to — so that they’re more easily seen by the viewer — are call-to-action buttons in a web design, or the subject of a photograph.

I’ll talk about a few tricks for increasing the visual weight of an object.

1. Give It a Different Color

When the color-contrast between an object and its surroundings (including its background) is high, the more able it is to garner our attention.

In the example above, notice how, even though the size, shape and margins of the stars are identical, the red star is able to get your attention simply because of how distinctive its color is compared to other elements in the composition.

2. Move It Away from Other Objects

One easy trick for increasing the visual weight of an object is distancing it from other objects. Adding plenty of negative space around the object separates it from other objects, which in turn makes the object stand out.

In the example above, look at how our eyes interpret the composition as two groups of rabbits: A big group of 12 rabbits and a small group consisting of only one rabbit. By being farther away from the others, the estranged rabbit is able to command our attention more than any other rabbit in the composition.

3. Make It Look Different

When things look alike, it’s naturally hard for us to differentiate them. So, quite simply, we can make the visual weight of an object heavier by making it look different from other objects.

Even a slight change in the style properties of an object can heavily influence its visual weight if objects in the composition look similar. In the above example, notice how the circle at the center of the first row is able to get our eyes’ attention compared to the other circles.

4. Point to It

A simple trick for increasing the visual weight of something is to direct the viewer’s eyes to it using visual queues such as arrows.

In the above example, check out how the visual weight of the house is increased because it’s surrounded by arrows that point to its location. No matter where our attention goes, we’re redirected to look at the house because of the arrows.

5. Make It Look Visually Complex

An ornate object attracts our eyes more when it’s set among simple and unadorned objects. We can make the appearance of an object complex by giving it textures, drop shadows, changing its shape, adding more color to it, and so forth.

In the example above, the multi-colored circle has the heaviest visual weight because the surrounding objects are styled plainly.

6. Make It Bigger

Making an object larger than the other objects around it will increase its visual weight. It’s a reasonable proposition: The more visual space an object takes up, the more visible it is.

In the example above, notice how our eyes are quickly drawn to the biggest heart . The only thing different with it is its size.

Visual weight is a simple but incredibly powerful design tool for strategically arranging elements so that more important elements are readily seen by our viewers.

What tricks do you use to increase the visual weight of an object? Share your advice in the comments.

HBR Blog Review: The Core Incompetencies of the Corporation

HBR-logo

Readers:

Gary HamelI am taking the day off of blogging to share with you a very thoughtful and insightful blog from The Harvard Business Review Blog Network written by Gary Hamel (photo right). Mr. Hamel blogged this on October 31, 2014 and it it titled The Core Incompetencies of the Corporation. Mr. Hamel is an influential business thinker, cofounder of Strategos and director of the Management Lab. He latest book is The Future of Management.

I hope you enjoy his blog as much as I did.

Best Regards,

Michael

The Core Incompetencies of the Corporation

Large organizations of all types suffer from an assortment of congenital disabilities that no amount of incremental therapy can cure. First, they are inertial. They are frequently caught out by the future and seldom change in the absence of a crisis. Deep change, when it happens, is belated and convulsive, and typically requires an overhaul of the leadership team. Absent the bloodshed, the dynamics of change in the world’s largest companies aren’t much different from what one sees in a poorly-governed, authoritarian regime – and for the same reason: there are few, if any, mechanisms that facilitate proactive bottom-up renewal.

Second, large organizations are incremental. Despite their resource advantages, incumbents are seldom the authors of game-changing innovation. It’s not that veteran CEOs discount the value of innovation; rather, they’ve inherited organizational structures and processes that are inherently toxic to break-out thinking and relentless experimentation. Strangely, most CEOs seem resigned to this fact, since few, if any, have tackled the challenge of innovation with the sort of zeal and persistence they’ve devoted to the pursuit of operational efficiency. Their preferred strategy seems to be to acquire young companies that haven’t yet lost their own innovation mojo (but upon acquisition most likely will).

And finally, large organizations are emotionally insipid. Managers know how to command obedience and diligence, but most are clueless when it comes to galvanizing the sort of volunteerism that animates life on the social web. Initiative, imagination, and passion can’t be commanded—they’re gifts. Every day, employees choose whether to bring those gifts to work or not, and the evidence suggests they usually leave them at home. In Gallup’s latest 142-country survey on the State of the Global Workplace, only 13% of employees were truly engaged in their work. Imagine, if you will, a car engine so woefully inefficient that only 13% of the gas it consumes actually combusts. That’s the sort of waste we’re talking about. Large organizations squander more human capability than they use.

Inertial. Incremental. Insipid. As the winds of creative destruction continue to strengthen, these infirmities will become even more debilitating. Few companies, though, have made much progress in eradicating them. Most of the recommended remedies—idea wikis, business incubators, online collaboration, design thinking, “authentic” leadership, et al—are no more than minor tweaks. They are unlikely to be any more effective than the dozens of “fixes” that came before them. Remember T-groups, total quality management, skunk works, high performance teams, “intrapreneurship,” re-engineering, the learning organization, communities of practice, knowledge management, and customer centricity? All of these were timely, and a few genuinely helpful, but none of them rendered organizations fundamentally more adaptable, innovative, or engaging. Band-Aids, braces, and bariatric surgery don’t fix genetic disorders.

To build organizations that are fit for the future, we have to go deeper, much deeper. When confronted by unprecedented challenges, like an inflection in the pace of change, the most important things to think about are the things we never think about—the taken-for-granted assumptions that are to us as unremarkable as water is to fish. The performance of any social system (be it a government, a religious denomination or a corporation), is ultimately limited by the paradigmatic beliefs of its members; by the core tenets that have been encapsulated in creeds and reified in structures.

Reflect for a moment on the development of constitutional democracy. Ancient and medieval societies were predicated on the “divine right of kings.” The sovereign was answerable only to God and royal edicts could not be countermanded. Society was ordered in descending ranks of royal privilege and everyone from dukes to peasants “knew their place.” To most of those who lived in this pre-democratic world, the idea of self-government would have been ludicrous, if it could have been imagined at all. Thankfully, a few brave souls like William Penn, Thomas Paine, and Patrick Henry not only imagined self-government, but devoted their lives to making it a reality. Today it’s the imperial alternative that’s unthinkable.

Until we challenge our foundational beliefs, we won’t be able to build organizations that are substantially more capable than the ones we have today. We will fail to build organizations that are as nimble as change itself. We will fail to make innovation an instinctual and intrinsic capability. We will fail to inspire extraordinary contributions from our colleagues and employees.

Most organizations are still feudal at their core, with a raft of institutionalized distinctions between thinkers and doers—between the executive class and everyone else. And most leaders still over-value alignment and conformance and under-value heterodoxy and heresy. Until this changes, our organizations will be substantially less capable than they might be.

This post is part of a series leading up to the 2014 Global Drucker Forum, taking place November 13-14 in Vienna, Austria. See the rest of the series here.

Steve Heller, Alberto Cairo, and The World in Terms of General Motors

World in Terms of GM Cutout

Readers:

The other day on Twitter, Albert Cairo tweeted about a great visual map he found in a 1938 issue of Fortune Magazine at Steve Heller’s Moving Sale on Saturday, June 28th, 2014 in New York City.

Alberto Cairo GM Tweet

Daily Heller Moving Sale

Steve Heller

Steve HellerSteven Heller wears many hats (in addition to the New York Yankees): For 33 years he was an art director at the New York Times, originally on the OpEd Page and for almost 30 of those years with the New York Times Book Review. Currently, he is co-chair of the MFA Designer as Author Department, Special Consultant to the President of SVA for New Programs, and writes the Visuals column for the New York Times Book Review.

He is the co-founder and co-chair (with Lita Talarico) of the MFA Designer as Author program at the School of Visual Arts, New York, where he lectures on the history of graphic design. Prior to this, he lectured for 14 years on the history of illustration in the MFA Illustration as Visual Essay program at the School of Visual arts. He also was director for ten years of SVA’s Modernism & Eclecticism: A History of American Graphic Design symposiums.

The World in Terms of General Motors

The visual in the December 1938 issue of Fortune Magazine was called The World in Terms of General Motors. It depicted a sketch map showing the location of (then) GM’s 110 plants. The spheres representing each plant are proportional (in volume) to their normal number of workers. The key numbers of the spheres are indexed on the map. The map does not include those manufacturing plants in which GM has less than 50% stock. The principal ones are Ethyl Gasoline Corp., Bendix Aviation Corp., Kinetic Chemicals, Inc., and North American Aviation, Inc.

Not shown are GM’s many non-manufacturing interests, domestic warehouses, etc.

So, finally, here is the complete map.

Enjoy!

Michael

[Click on the map image to enlarge]

IMG_0354

 

MicroStrategy Report Optimization: Components of Performance

Readers:

Today, I am adding the second post in my MicroStrategy Report Optimization series. This will be a multi-part series (I will leave it open-ended so I can continue to add to it).

Today, we will look at the components that comprise performance.

Best Regards,

Michael

Source: MicroStrategy University, Deploying MicroStrategy High Performance BI, V9.3.1, MicroStrategy, Inc. September, 2013.

Components of Performance

There are five key layers or components that a typical BI query must go through. They are:

  • Caching Options
  • Data Transfer
  • System Architecture and Configuration
  • Client rendering or Data Presentation
  • Data Warehouse Access

The components above are not listed in any specific order of access during the execution of a query. The image below illustrates the five components.

The Components of High Performance

Caching and Intelligent Cubes

MicroStrategy’s memory technology is engineered to meet the increased demand for higher BI performance, which is driven by the rapid expansion of both data volumes and the number of BI users in organizations across industries. MicroStrategy accelerates performance by pre-calculating computations and placing the results into its memory acceleration engine to dramatically improve real-time query performance.

Data Transfer

Data transfer over one or more networks are a very important component of a BI implementation. A slow or poorly tuned network performance in any of those transfers will translate into poor performance from a report or a dashboard execution perspective.

System Architecture and Configuration

Successful BI applications accelerate user adoption and enhance productivity, resulting in demand for more users, data, and reports. MicroStrategy provides the ability to adapt quickly to constant changes and evolve along with business requirements. MicroStrategy Intelligence Server hs been proven in real-world scenarios to deliver the highest performance at scale with the fewest servers and minimum IT overhead.

Data Presentation

Dashboards provide graphical, executive views into KPIs, enabling quick business insights. MicroStrategy enables higher performing dashboards, averaging 30-45% faster execution and interactivity. Using new compression methods, MicroStrategy dashboards have a smaller footprint than ever before – up to to 55% smaller – resulting in faster delivery using less network bandwidth. Dashboards deliver ever more analysis and data for end-users.

Data Warehouse Access

High performance BI starts with optimizing SQL queries to retrieve results from the database as quickly as possible. BI performance is dependent largely on the time that the queries take to execute in the database. An average reporting request usually takes 40 seconds to complete, out of which 34 seconds, or 85% of the query time, is spent executing in the database.

Therefore, it is critical to optimize report queries to reduce database execution time.

Wisdom of Crowds 2014: Success with Business Intelligence and Technology Priorities

Readers:

Howard DresnerLast week, Howard Dresner released the 2014 Edition of his Wisdom of Crowds Business Intelligence Market Study.

Mr. Dresner is Chief Research Officer of Dresner Advisory Services, LLC, an independent advisory firm and a well-known authority and author in the areas of Business Intelligence and Performance Management.

Howard has 32 years of IT industry experience with 24 years in the Business Intelligence market.

He spent 13 years at Gartner, where he was a Research Fellow and Lead Analyst for BI. He also served as Chief Strategy Officer at Hyperion Solutions prior to forming Dresner Advisory Services in 2007.

Howard is a frequent speaker around the globe and has published two books on the subject – including: Profiles in Performance – Business Intelligence Journeys and the Roadmap for Change (John Wiley & Sons, November 2009) and The Performance Management Revolution: Business Results through Insight and Action (John Wiley & Sons, November 2007).

Through the Wisdom of Crowds Business Intelligence market research reports, Howard engages with a global community to redefine how research is created and shared.

I thought I would share a peek into his report with you on the topic of Success with Business Intelligence and Technology Priorities.

Mr. Dresner notes that with a few exceptions, reports of success with BI deviate little based on specific technology priorities. Those claiming success are slightly more likely to favor in-memory analysis and data mining and advanced algorithms. Those that are less successful were more likely to favor big data, analytical applications, software-as-a-service / cloud and location intelligence.

As part of his survey, when asked for reasons why business intelligence fails, respondents point to shortfalls and constraints surrounding data that include “tools” and “time,” but also “business,” “organization” and “management”.

Primary reasons for failure include: a lack of management understanding or appreciation of BI, a predominant focus upon technology vs. solving business problems and a lack of skills and resources to deliver solutions.

To visualize the data associated with success and not being successful, Mr. Dresner uses a radar chart (see chart below). A radar chart is a graphical method of displaying multivariate data in the form of a two-dimensional chart of three or more quantitative variables represented on axes starting from the same point. The relative position and angle of the axes is typically uninformative.

The radar chart is also known as web chart, spider chart, star chart, star plot, cobweb chart, irregular polygon, polar chart, or kiviat diagram.

As I delve deeper into the report, I will share other insights with you.

Best regards,

Michael

Wisdom of Crowds - Success

Dr. Dobbs Journal: The Corruption of Agile (The Agile Holocracy) – Part 3 of 3

Readers:

In my last post, I included a recent interview Andrew Binstock, Editor in Chief of Dr. Dobbs Journal, had with Dave Thomas about the corruption of Agile and how many people are misunderstanding what the Agile Manifesto really said.

Allen HolubToday, I am continuing with the third and final part of my series titled The Corruption of Agile by highlighting thoughts from one of the key thinkers in the area of agile, Allen Holub. Allen is a consultant, trainer, and speaker, specializing in Lean/Agile process infusion, Agile/OO architecture, and cloud-based web-application development. He’s worn every hat from grunt programmer to CTO, and has written hundreds of magazine articles for various technical publications and a dozen books, including Holub on Patterns: Learning Design Patterns by Looking at Code. He is a regular speaker at various conferences, worldwide.

In a recent blog entry in Dr. Dobbs Journal titled The Agile Holocracy, Allen noted that agile is a culture, not a set of practices. It is upper management’s job to establish that culture, and then let it work. A holocratic organization is one of the better ways to do that.

Mr. Holub notes that the word holocracy popped up in a recent Dilbert cartoon, used incorrectly as a synonym for both a flat organizational structure and, as the pointy haired boss says, “wander[ing] around.” Nonetheless, full-on agile organizations have many of the characteristics of a holocracy, so Allen thought it was worth exploring the concept.

The term holocracy was coined by Artur Koestler in his 1967 book, The Ghost in the Machine, which is actually a discussion of the human brain. Koestler’s thinking applies to social organizations as well, however. A holocracy is made up of autonomous, self-reliant units called holons (from the Greek word for “whole”). The holons are simultaneously independent from and dependent on the organization that they comprise. That is, a holocracy is simultaneously a whole and its parts.

Kosetler uses our own brains as an example. The cerebellum (the “reasoning” brain) is largely independent on the amygdala (the so-called “lizard brain”). These two sub-brains operate independently under their own rules, but interact in a way that allows the whole system to behave both coherently and in a way that you couldn’t predict from looking at a single subsystem. This is a kind of emergence; the coherent behavior that arises from the complex interactions of the rules and strategies of the independent holons is more sophisticated than behavior of the parts. The ghost is the thing that you can’t predict just by looking at the parts.

Koestler also points out that when one subsystem dominates, the whole system can become pathological. When your lizard brain hears a loud noise and says “panic!,” your cerebellum counters with, “no, that’s just an electric guitar and a gazillion-watt amp” and overrides it. The synthesis is a feeling of excitement that the concert’s starting. If the lizard brain wins, everybody in the stadium gets trampled.

The notion of holocracy works well in agile organizations. In fact, I’d say that some level of holocratic structure is essential. Independent units — teams or individuals — are responsible for specific organizational roles, and interact with one another in a synergistic (to use an overused word) way. A person is holon, and so is a team. Each holon is both independent and part of the whole. Each holon is responsible for itself, but is also responsible for the success of the whole organization. The holons carry out well-defined roles, and are responsible for doing whatever they have to do to succeed in those roles. Nobody orders anybody around. The teams and the people are responsible for defining and executing their own tasks.

Getting back to Dilbert, holocratic organizations do have a flat hierarchy. They are peer-to-peer networks, not trees, and there’s no place for any sort of “middle management.” The executives are the organization’s lizard brain: They set the direction and support the broad culture. The teams are the cerebellum: Thinking out the details and getting the processes to work. The synthesis of those roles yields a functional agile organization. If either holon is dominant (that is, if agile practice exists without a supporting culture, or if the executives perpetuate command-and-control, or if the teams get to do everything they want without regard to budget or scope), everybody gets trampled.

There isn’t even a “CEO” in the captain-of-the-ship sense. Instead, the holons (both people and teams) communicate with each other in order to tune what they’re doing. In the same way that people talk to each other, teams interact horizontally. For example, teams can “inject” members into other teams. Spotify, for example, has a “guild” system. All the database folks from all of the teams get together occasionally for Database-Guild meetings, and so forth. Think of this arrangement as a database-guild holon that injects members into the development-team holons.

Holocratic organizations aren’t fantasies. Probably the most well-known is W.L. Gore, Inc., as described in Malcolm Gladwell’s Tipping Point. There are no formal titles and no hierarchical structure. People have “sponsors,” but nobody reports to anybody.

The main objections to the viability of a holocracy seem to come from people who confuse holocracy with anarchy — everybody doing whatever they want. That’s not what I’m describing. A holocracy is highly disciplined. You take your responsibilities seriously, and work hard both to be effective and to make everybody else successful. Communication and collaboration are central to both functions, so everybody does that.

Similarly, holocracy is not Communism. The people who contribute more are rewarded accordingly. However, compensation has to be transparent and rational. Secrets undermine the collaborative nature of the system.

Dysfunction happens when one holon becomes dominant. An out-of-control “executive” holon, for example, can destroy the agility of the organization. I’ve seen teams, departments, and whole companies brought to their knees by pathological “leaders” intent on dominating, who think that somebody has to “run” things. The mandates that come from these people do nothing but add dysfunction. I’m not talking about micromanagement, which is also a sort of disease. Dysfunction happens any time somebody can’t do something because they need permission, or won’t do something because they’re afraid of some repercussion. The holons (teams and individuals) must be empowered to fulfill their roles.

Of course, there’s no reason for some of the holons not to be tasked with the health of others. For example, one responsibility of the “executive” holon is to assure that company has an effective internal culture. If a team becomes dysfunctional, the “executive” holon’s job is to help the team heal, not by ordering people around, but by providing training, mentorship, etc. If that doesn’t work, though, the “executive” holon could act like an antibody. The immune system is part of a healthy brain. The core value in a holocracy is trust. Hierarchical command/control organizations are built on mistrust. They assume that nobody beneath you in the hierachy is truly self sufficient and competent, so they impose paternalistic governance practices that force these assumed-incompetent players to behave. A holocracy trusts everybody to do their work in the best way possible.

Since trust and assumed competence are also firmly ingrained in the Agile Principles, there’s a good match here. Everybody’s got to be a grownup, though. I once heard Aliestar Cockburn answer the criticism “your methods won’t work in the real world because they require nothing but A players” by saying that making good software always requires A players, regardless of your process. I agree.

As a final note, Holacracy.org adapted Kosteler’s notions into a social/organizational milieu, and serves as an interesting example of another functional variant of an holocracy. Everybody in the Holacracy.org is literally (in the legal sense) a partner. There are no bosses, and there is no CEO. I’m not a huge fan of Holocracy.org’s formalization, but they’re prominent enough to deserve mention. For one thing, I’m offended by the way that Holacracy.org has trademarked Kosetler’s term. The trademark isn’t enforceable, given prior use, but they have no right to set themselves up as the arbiter of somebody else’s idea. It’s like somebody trademarking “agile.” Moreover, I don’t particularly like their fixed rules (documented in a Constitution), which seems to me to fly in the face of the core principle of self organization.

I’ve said this before, but agile is a culture, not a set of practices. It is upper management’s job to establish that culture, and then let it work. A holocratic organization is one of the better ways to do that.

———————————————————————————–

Source: Allen Holub, The Agile Holocracy, Dr. Dobbs Journal, March 14, 2014, http://www.drdobbs.com/architecture-and-design/the-agile-holocracy/240166629.

 

Dr. Dobbs Journal: The Corruption of Agile (or What the Agile Manifesto Really Said) – Part 2 of 3

Readers:

In my last post, I included a recent article from Andrew Binstock, who is the Editor in Chief of Dr. Dobbs Journal. Mr. Binstock expressed his concerns about how we are corrupting Agile.

Dave ThomasToday, I am continuing with Part 2 of my The Corruption of Agile series by highlighting thoughts from one of the founding authors of the Agile Manifesto, Dave Thomas. Dave (photo, right) is a coauthor of the legendary Pragmatic Programmer book, one of the authors of the Agile Manifesto, a publisher, speaker, and the man who brought Ruby to the masses.

In a recent interview with Mr. Binstock, Dave discussed what he feels is wrong with Agile. But, before we get started, let’s review what the Agile Manifesto really said. This is verbatim from the Agile Manifesto website.

 

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more. [2]

The Corruption of Agile – Andrew Binstock’s Interview with Dave Thomas [1]

AB: Let me move to the Agile Manifesto. You were one of the original signatories…
DT: Yes, yes. There were 17 of us that met in Snowbird in Utah in February 2001; and we came up with the four values and the common ground and practices. The way we came up with it was not something I’d ever experienced before. There were 17 people and everyone had their own ax to grind and their own particular viewpoint on what was best. And within a couple of hours, we’d come up with a way of working that let us discuss the principles behind what we were doing without going into the details.So the framework itself, the actual four values, came out in half a day. It just kind of came. I think everyone kind of knew what they wanted to say. I think it was actually Martin Fowler and I — everyone else was having lunch — we were kind of sitting at a whiteboard just chatting through things and we came up with the “we value A over B” formulation, which as it turns out, has worked out really well.
AB: I think that perhaps a limitation is that a lot of people have interpreted it as “no B whatsoever.”DT: Indeed! And, in fact, we recognized that might happen at the time, and we put in the little phrase at the bottom: “whereas we value B, we value A more.” So, we thought that would happen and we tried to stop it, but, of course, we…AB: …can never control…

DT: Yes, that was the depressing thing for me. I came away from Snowbird feeling really happy. And within a month, I realize it wasn’t going to work. And I have not been involved in anything even called “Agile” until last month.
AB: Last month?
DT: That’s right, last month. I have not gone to any Agile conferences. I have not joined the Agile Alliance.
AB: Why is that?
DT: Because it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.
AB: Yes.
DT: And so now in the software world, if you’re selling something and it doesn’t have the word “Agile” somewhere in the title, it’s not good. And I hate that because we had something that was…it was my best attempt at the time to present a set of free-standing, self-contained values that could be applied by all. And now it’s just become mush. It’s become devalued to the point where it doesn’t mean anything.
DT: I also have a pure English-language abhorrence to the people who use Agile as a noun. As in “I do Agile.” No you don’t. It’s like saying “I do orange.”
AB: When you were meeting at Snowbird, was there a feeling there that you were doing something important that was going to change software?DT: Good question.AB: The fact that you chose the term “manifesto” suggests that you were planting a flag.DT: There was a lot of discussion at the time about what it should be called. And, to be honest, I can’t remember to what extent we were thinking of posterity when we came up with the word “manifesto.” Even the word Agile was debated a lot.

AB: That’s what I’ve heard.

DT: I think we discussed “lightweight.” There was some sense that this was going to be bigger than the 17 of us because we agreed on the last day that Ward [Cunningham] was to go create a site that would allow people to sign up. Ward is someone who is always building community. And I think we all went along thinking that would be a really good way to spread the word. But the reality was that I don’t think any of us were particularly marketing people. The fact that it took off as quickly as it did was that we just happened to say the right thing at the right time. We didn’t actively push it particularly, it just kind of pushed itself or actually pulled itself.

Next: Allen Holub and The Agile Holocracy

Bonus Section: The 12 Principles behind the Agile Manifesto

For you folks that have never read the actual Agile Manifesto, I have provided a copy of its guiding principles here for your review.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. [2]

———————————————————————————–

Sources:

[1] Andrew Binstock, Dave Thomas Interview: The Corruption of Agile; Ruby and Elixir; Katas and More, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/dave-thomas-interview-the-corruption-of/240166688?pgno=3.

[2] Kent Beck et al, Manifesto for Agile Software Development, The Lodge at Snowbird Ski Resort, Utah, February 11-13, 2001, http://agilemanifesto.org/.

 

 

Dr. Dobbs Journal: The Corruption of Agile – Part 1 of 3

Readers:

I have been in the Computer Science / Information Technology / Management Information Systems profession a long time. There are times when I need to take a break from all of the noise going on in our profession and revisit words and thoughts from the people I consider my mentors. These are the people who helped me become a better programmer, a better thinker, and learn to question everything.

One of my favorite magazines that I have read since my early days in this profession is Dr. Dobbs Journal. Reading articles in this wonderful magazine from many of the thought leaders (e.g., Scott W. Ambler, Allen Holub, Bruce Eckel, Larry O’Brien, Dave Thomas, Andrew Koenig, etc.), who taught courses early on at various conventions I have attended during my actual computer language programming days (e.g., C, C++, Java), remind me of the principles and personal practices I have let slip or ignore with all of our new drag-n-drop GUI-related tools.

Andrew BinstockI came across this article from Andrew Binstock (photo right), who is the Editor in Chief of Dr. Dobbs Journal. Prior to joining Dr. Dobb’s Journal, Andrew Binstock worked as a technology analyst, as well as a columnist for SD Times, a reviewer for InfoWorld, and the editor of UNIX Review. Earlier, he was a senior manager at Price Waterhouse. He began his career in software development in the early 1980’s.

I have included Mr. Binstock’s recent editorial about his concerns about how we are corrupting Agile in it’s entirety below. In Parts 2 and 3 of this series, I will explore some interesting thoughts about the Agile Manifesto and an interesting technique developed by Dave Thomas to continuously improve our programming skills.

Best Regards,

Michael

The Corruption of Agile

by Andrew Binstock, Editor in Chief, Dr. Dobbs Journal

What was intended as a set of personal practices has become a doctrine. And despite the mainstream adoption of Agile, the loss of its original intent has undermined its effectiveness.

Many people over the years have discussed their distress with the religious tone that cloaks the implementation of Agile practices. Particularly from the testing side of the world, there is a lot of “should,” “should not,” and “can do better next time” dialogue that sounds more like a man trying to fix ethical lapses than a developer writing code. When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than the a function of careful discipline and development rigor.The disconnect between today’s Agile view and earlier reality is equally evident in the wanton bashing of the waterfall model. To get any programmer today to adopt your recommendation, simply state that not doing so is just a new way of doing waterfall. Watch his toes curl despite never having used waterfall, nor seemingly having any awareness that it served the industry really well for decades. What, was everyone in that bygone era a fool?Alan Kay was entirely right when he said that programming today has become a pop culture: “Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?”

It will pain some readers to know that the vast, error-free Internet predates Agile and even predates TDD. Crazy, right?

What I’m saying here is certainly not new. The fascination with today’s way of doing things and the view that it is the one true path to good code is a seemingly permanent part of the programming culture. But it has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about. It’s important to remember that the Agile manifesto stated values, not practices. Immediately, though, values were translated into programming practices by consultants and, quickly, the former was lost. One of the original formulators of the manifesto, Dave Thomas, whom I interviewed this week, states his realization that a month after the manifesto was written it was already being corrupted: “…it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.”

What’s interesting in Thomas’s account is the view that Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.

By pure coincidence, Allen Holub has been driving this point home in several blog posts, the most recent of which is a brilliant little piece that reminds us that Agile is a culture, not a set of practices. As he has previously explained, just because an organization is using scrum, doesn’t mean it’s Agile. He could have said the same thing about TDD, continuous integration, pair programming, or the like.

Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it’s Agile, if not, then it’s doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile. Yeah, I know, crazy, right?

Next: What the Agile Manifesto Really Said

———————————————————————————–

Source: Andrew Binstock, The Corruption of Agile, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698.

Andrew Binstock can be reached at alb@drdobbs.com or via Twitter at platypusguy

Bryan Redux #2: Removing Sections of a Report via URL API

Readers:

Here is another blog re-post from my friend, Bryan Brandow’s MicroStrategy site.

If you want to directly visit Bryan old site, the URL is http://www.bryanbrandow.com.

Best Regards,

Michael

Bryan originally posted this on July 22, 2011.

Removing Sections of a Report via URL API

WhBryan Brandowile working with the Web SDK to try to make a small customization, I stumbled on a pretty useful set of URL API codes that allow you to quickly modify the Report Page by removing various elements.  While such customizations are common, I wasn’t aware that they were available out of the box.  I would think that these would be very useful in doing simple linking to reports via an IFrame from another application, such as a Portal.

The trick to get the URL for a Report by right clicking it in Web, choosing Properties, and then copying the Link at the bottom.  Now, locate the src section of the URL:

ASP: &src=Main.aspx.4001 

JSP: &src=mstrweb.4001

and add in one of the transforms just before the .4001.

Available transforms that I’ve found:

reportNoHeader

reportNoHeaderNoFooter

reportNoHeaderNoFooterNoPath

reportNoHeaderNoFooterNoPathNoToolbar

Example:

ASP: &src=Main.aspx.reportNoHeader.4001

JSP: &src=mstrweb.reportNoHeader.4001

Unfortunately, these are actual transforms and not flags, so you can’t mix and match to fit your needs (for example, if you only want to hide the toolbar, reportNoToolbar will NOT work).  Those are the only 4 that you can use that I’ve found, but they may be handy in a pinch and best of all, not require customization work to use.

Update:

Another method of doing this that does let you pick and choose and supports documents as well:

&hiddenSections=header,footer,path,dockTop

Place that code in the URL, for example (Note: I have shown this on multiple lines. You should paste this in as one long line with no line breaks):

http://webserver/Microstrategy/asp/Main.aspx?Server=ISERVER&Project=PROJECT&Port=0&evt=2048001
&hiddenSections=header,footer,path,
dockTop&src=Main.aspx.2048001
&visMode=0&documentID=04AACFE445AD69198676C8AD56245118
&currentViewMedia=2

List of options (case-sensitive):

  • header
  • path
  • dockTop
  • dockLeft
  • dockRight
  • error
  • content
  • dockBottom
  • footer

Bryan’s Blog Entry Link:  http://www.bryanbrandow.com/2011/07/removing-sections-of-report-via-url-api.html

PRIME: MicroStrategy Announces Release of Cloud Based, In-Memory Analytics Service, Running at Multi-Terabyte Scale

MicroStrategy Cloud’s New Parallel Relational In-Memory Engine (PRIME) Provides High Performance On Big Data Allowing Companies to Build High-Scale, Easy-to-Use Information Driven Apps

Las Vegas, NV, January 28, 2014 – MicroStrategy® Incorporated (Nasdaq: MSTR), a leading worldwide provider of enterprise software platforms, today announced the availability of its new Parallel Relational In-Memory Engine (PRIME) option for the MicroStrategy Cloud™ at its annual user conference, MicroStrategy World 2014, in Las Vegas. MicroStrategy PRIME™ is a massively scalable, cloud-based, in-memory analytics service designed to deliver extremely high performance for complex analytical applications that have the largest data sets and highest user concurrency. Facebook has successfully built high value information-driven applications with the technology that powers MicroStrategy PRIME.

“Rising data volumes are fueling demand for compelling, easy-to-use analytical applications with the power to revolutionize existing business processes for thousands or tens of thousands of employees, customers, or partners,” said Michael Saylor, CEO, MicroStrategy Incorporated. “MicroStrategy PRIME has been built from the ground up to support the engineering challenges associated with development of these powerful new information-driven apps. This innovative service will allow organizations to derive maximum value from their information by making their Big Data assets actionable.”

Most organizations struggle to harness the value of the information in their Big Data stores due to poor performance. Big Data technologies can store large amounts of information, but distributing that information in an interactive manner to thousands of users with existing commercially available technologies is a huge challenge, often resulting in risky, multi-year projects. MicroStrategy PRIME breaks new ground by tightly coupling a state-of-the art visualization and dashboarding engine with an innovative massively parallel in-memory data store. This architecture allows companies to build highly interactive applications that deliver responses to hundreds of thousands of users in a fraction of the time and cost of other approaches. MicroStrategy PRIME acts as a performance accelerator, opening up the data in databases to a much larger user population, driving new demand for information.

MicroStrategy PRIME combines:

  • Massively parallel, distributed, in-memory architecture for extreme scale. MicroStrategy PRIME is built on an in-memory, highly distributed, massively parallel architecture, designed to run on cost effective commodity hardware. Complex analytics problems can be partitioned across hundreds of CPU cores and nodes to achieve unprecedented performance. MicroStrategy has worked closely with leading hardware vendors to take full advantage of today’s multi-core, high memory servers.
  • Tightly integrated dashboard engine for beautiful, easy-to-use applications. MicroStrategy PRIME includes a state-of-the-art dashboard and data exploration engine, built on the MicroStrategy Analytics Platform™. The visualization engine includes hundreds of optimizations designed specifically for the in-memory data store. This engine enables customers to build complete, immersive applications that deliver high-speed response.
  • Cloud-based delivery for rapid deployment. MicroStrategy PRIME is available as a service on MicroStrategy Cloud, MicroStrategy’s world-class Cloud Analytics platform. MicroStrategy Cloud offers a complete service, including the infrastructure, people and processes to enable customers to quickly and easily develop and deploy high-scale, information-driven applications.

About MicroStrategy Incorporated

Founded in 1989, MicroStrategy (Nasdaq: MSTR) is a leading worldwide provider of enterprise software platforms. The Company’s mission is to provide the most flexible, powerful, scalable and user-friendly platforms for analytics, mobile, identity and loyalty, offered either on premises or in the cloud.

The MicroStrategy Analytics Platform™ enables leading organizations to analyze vast amounts of data and distribute actionable business insight throughout the enterprise. Our analytics platform delivers reports and dashboards, and enables users to conduct ad hoc analysis and share their insights anywhere, anytime. MicroStrategy Mobile™ lets organizations rapidly build information-rich applications that combine multimedia, transactions, analytics, and custom workflows. The MicroStrategy Identity Platform™ (branded as MicroStrategy Usher™) provides organizations the ability to develop a secure mobile app for identity and credentials. The MicroStrategy Loyalty Platform™ (branded as MicroStrategy Alert) is a next-generation, mobile customer loyalty and engagement solution. To learn more about MicroStrategy, visit www.microstrategy.com and follow us on Facebook and Twitter.

MicroStrategy, MicroStrategy Analytics Platform, MicroStrategy Mobile, MicroStrategy Identity Platform, MicroStrategy Loyalty Platform, MicroStrategy Usher, MicroStrategy Cloud and MicroStrategy PRIME are either trademarks or registered trademarks of MicroStrategy Incorporated in the United States and certain other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.