Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

The best and worst thing about being an architect

Leave a comment Posted by on July 10, 2018

pros-cons[1]

Many things about IT architecture simultaneously attract and repulse people. Architects are technical decision makers but often leave the implementation to others. They translate between the business and technical, taking an economic view of IT.

Fortunately and unfortunately, architects are not managers. While this frees them from budgets, staffing and directly managing people; it also means every decision they make is really a decision making aide for other managers. Architects are all responsibility but no authority.

Architectural authority is only granted through the authority of the management responsible. While managers can perform an architecture function, often in smaller teams, architects are usually senior individual contributor roles. Teams implement an architect’s designs because the manager says so.

Acting through managers’ authority also means architects must influence to ensure their architectures are adhered to. While some architecture teams take a more dictatorial approach, most architecture teams ensure their designs have clear benefits for all stakeholders and contributors. If a team sees no value to them from following the architects’ directions, they can often ignore it.

Even governance – ensuring other’s designs are complete, follow the broader architectural vision and are implemented as specified – works via influence. A lower level manager may baulk at his or her team doing significant work that does not benefit their team but there are often constraints or impacts outside their team. Higher level management must step in to ensure teams meet broader business goals, not just their own.

Like managers, architects engage with multiple teams and senior management. They need to communicate at different levels with different strategies (like management), switch frequently (like management) and are ultimately judged by outcomes (like management).

This means the architect depends on others to ultimately implement the systems involved. Like managers, architects need to tailor their output to their teams. An architect can delegate much of the lower-level details to a capable team familiar with the problem may need only high-level direction. An inexperienced team working on an unfamiliar problem may need a lot more help. An architect’s failure can doom the project.

Like management, architects handle ambiguity and conflicting requirements. These require a mix of technical, business and political knowledge to navigate but also allow the architect (or manager) to demonstrate his or her experience and value. Architects, like managers, should be looking at the bigger picture, considering the economic impact and giving non-technical solutions their due.

Of course, there are many things managers need to consider that architects do not. For example, architects can rarely delegate. Architects are individual contributors tasked with ensuring minor, often technical details do not compromise strategic goals.

Unlike management, architects need to evangelize their work and value more than management because they lack management’s built-in responsibilities. They may be the driving force behind a project but the success may be attributed elsewhere.

However, the overlap between management and architecture is larger than many realise. This overlap is why architecture is a senior role. When an architect sneezes, their areas of responsibility catch a cold. Architects are not managers but they players in the same game. They do a lot of managing anyway, whether that be up or down.

Image from https://smallbiztrends.com/2011/12/pros-cons-buying-franchise.html. Used under Creative Commons license.

Architecture, Op-Ed

Talking Non-Tech

Leave a comment Posted by on June 1, 2018

IT architects often pride themselves on their technical knowledge. Tasked with designing a system from end-to-end and taking responsibility for that design, they need to ensure the details are right. They also need to demonstrate technical prowess to earn respect from technical developers and engineers.

However, as discussed in previous posts, architects also have to talk to non-technical people to gather requirements, understand the business context and assure them that a design will meet their needs. For people used to delving into the technical details, this context and mindset switch can be challenging.

First, understand the value the architect’s proposed changes bring to stakeholders and organization. Understand not just what each stakeholder has asked for but how that stakeholder’s performance is measured and describe the impact of proposals in those terms.

Taking an operations manager as an example, describe how this will reduce incident frequency or severity. For a salesperson, relate this to imminent or key deals. For any management, ensure they understand how the changes relate to KPIs, long-term objectives or organizational policies.

A quick way to do this is to describe a technical change then ask “So what?”. Relate it to each stakeholder in a sentence or two then invite questions. Take note of anything asked and ensure it is covered next time.

Sometimes non-technical people suggest technical solutions. While most IT architect’s immediate reaction is to dismiss these as ill-informed, a better response is to understand the reasons behind it. Did this suggestion work last time? Is the relative cost for the asker small? Is a suggested tool the only one the asker is familiar with?

A better response from an architect is to evaluate suggestions and provide quicker, cheaper and/or better alternatives. Sometimes, however, it is important to buy-in by using elements of their suggestion, even if it is technically suboptimal.

Unless the organization has prescribed formulas or a culture of doing so, avoid trying to express impacts in financial terms. Chances are architects will get it wrong. Be careful using jargon or discipline-specific terms, too. Technical people cringe when non-technical people misuse technical terms. It happens the other way around, too.

Describe the context of a technical change in both technical and business terms. What existing systems or processes are impacted? What can we do now that we could not before? What can we do better or cheaper? What additional work is required or what work is saved?

No system exists in a vacuum and there are always flow-on effects for every change. If an architect cannot articulate these, chances are the requirements were not fully understood or analysis was lacking.

Describe the impact constraints have on the design or team implementing the design. Do not just list them (“We only have three engineers”). Say how this impacts the solution (“Option A is a better solution but, because we have a small team and a tight deadline, we are going for option B”).

Everyone in the organization has to deal with constraints. Sharing them helps build trust across teams. It also invites stakeholders, who sometimes have more experience, to suggest better ways of dealing with them.

Produce and use good quality communication. Consider using multiple views of a solution for different audiences, emphasizing different aspects. Use aesthetically pleasing diagrams with consistent use of symbols and colour. Do not be afraid of detail – it gives the audience the impression you have a deep understanding of the problem and solution – but ensure the communication is broad, covering the value and context as outlined above, instead of deep. Provide overviews or summaries to help time challenged people understand important points.

Communication should also cover solutions that were not selected or implemented. The implemented design or change will be evident. Understanding what alternatives were considered is often forgotten, particularly for trade-offs or others’ suggestions.

Beyond communicating better with non-technical people, these practices help architects understand the impact of technical changes on the organization beyond the immediate. It raises questions about larger impacts and exposes gaps in the architects understanding. It also helps build relationships.

Ultimately, being able to communicate effectively with non-technical people makes the architect a better architect. IT architects are more than just designers. They are collaborators and evangelists and they cannot do this if they can only talk and think like engineers. Architects are often the face of the team, department or company and the impression the architect needs to make a good impression.

Moreover, an architect’s technical solution exists within the organization’s social and political environments, not just technical. The architect is responsible for their work’s political and organizational success, too.

Image Credit: http://www.thebluediamondgallery.com/wooden-tile/v/value.html under Creative Commons 3 License (CC BY-SA 3.0)

Architecture , , , , ,

Toppling alpha developers

Leave a comment Posted by on May 18, 2018
Building blocks

Many people are attracted to software development because they love technology and development. Viewing it more as a hobby they are paid to undertake, they gladly spend time outside work solving that nagging problem, mucking around with the newest framework, contributing to open source software or exploring opinions on Twitter.

There is a subset of software developers that takes this to extremes. It is possible for someone that does not “eat and breathe” code to still take pride in their work, to still be a craftsperson or to want to learn more and improve. However, alpha developers make software development part of their identity and their desire for respect drives them to competitiveness.

From a hiring organization’s perspective, these alpha software developers are wonderful. Their pride dictates they produce high-quality work, often at the expense of their personal time. Training costs are minimal because they already know or quickly assimilate new tools, frameworks or techniques. Their competitiveness can force everyone to produce and learn more. They are happy to leave business decisions to others and focus solely on the technical. While these all have downsides, successful companies have learned to temper them.

However, alpha software developers create barriers. Alpha developers’ pride compels them to take technical leadership roles and demand others live up to their standards. Their knowledge of new tools and techniques and almost overriding urge to try them out can shut out discussions of other solutions. For those less enamoured with software development, alpha developers can be intimidating.

When asked to train others, alpha developers feel that owning one’s technical development and career path is a rite of passage. It is not that they look down on people who know less, more that alpha developers made the effort to train themselves so why should others be given special treatment?

Meanwhile, alpha developers feel their performance is judged on their own output and helping others interferes with that. Indeed, alpha developers will work around other developers if they feel they have to “save the project” by rewriting others’ code or taking on others’ work out of impatience.

This problem is exacerbated when alpha developers move into leadership positions. When hiring new developers, they perceive alpha developers as superior and hire them over others. When evaluating others, they reward alpha qualities.

Focusing on alpha software developers creates a monoculture, focused inward on technical prowess and knowledge. Decisions need broad, representative viewpoints. While few companies will have ample members of the target audience on staff, few companies’ target audiences are solely alpha software developers.

This relegates non-alpha developers to permanent “junior” roles. This blocks their career progression even though they may be well suited to roles that software development feeds into like business analysis, user experience, consulting, quality assurance, IT administration or solution architecture.

This also risks the competitiveness between alpha developers boiling over to conflict or burnout. Like a sports teams, having too many ego-driven superstars creates problems. Teams work best with people in a variety of roles and software development is a team sport.

Solving a problem like this, particularly something a deeply ingrained in software development culture, is not simple.

The first reaction is to move away from using lines of code or other similarly easily measured metrics as the primary determinants of productivity to ones that indicate the success of the project. This encourages a team-centric view of productivity, not individual-centric.

However, the problem is deeper than that. Like using the term “craftsperson” instead of “craftsman” at the start of this post, we need specific language to drive specific thinking. It is hard to conceive of ways to drive value without terms to describe them.

For example, a “developer experience” engineer could focus on improving the efficiency of existing developers and hastening the onboarding of new developers. While documentation is part of this role, its focus is more on fixing inconsistent APIs, gathering useful diagnostics, ensuring error messages are complete and descriptive, replacing or fixing buggy libraries and improving internal tool reliability.

This role focuses on the productivity of other developers and understanding how they work instead of raw lines of code. This person should not get too involved in the internals of the software. Otherwise, he or she may start to overlook or forgive bad practices.

Another potential role is a “business process integration” engineer. Working on a lower level than a user experience engineer, they look at product customization, integrations and automation/orchestration opportunities. For internal systems, this could be about integrating the system into a Business Process Management (BPM) or workflow solution. For external systems, this is similar to a customer-facing solution architect but works with the code directly to help users customize or leverage the product.

This role requires an understanding of the broader business context, how software is used by the organization and what the organization views as important. It is a good conduit into business analysis or enterprise architecture.

This all boils down to a search for value. While focusing on software is what others would expect software developers to do, focusing it to the exclusion of some of the software development community is a poor strategy. We need to change how we view and measure our software developers and change who we see as aspirational.

Image from https://commons.wikimedia.org/wiki/File:Autism.jpg. Used under creative commons license.

Op-Ed, Software Development , , , , ,

Requirements and leadership, not design, are the keys to architecture

Leave a comment Posted by on May 8, 2018

Listen Understand Act

Many IT engineers aspire to be architects. They want to dictate the course of their products or services, leading their fellow engineers. To do so, they focus on designing the best and largest systems, learning all about design patterns, notations and understanding technology from top-to-bottom.

However, if such a thing can be said to exist, even the best design is wasted if it does not solve the right problem. Architects should start here, instead.

Depending on the organization, requirements are often supplied by product management, business analysts or management. During requirements analysis, architect validation identifies ambiguities, omissions, estimated time and resource costs and likely tradeoffs. The resulting requirements and priorities may differ substantially from the original as trade-offs and discoveries are made.

Requirements often present the business understanding of what technology should do, not the most impactful or beneficial things technology can do. Architects are in the best place bridge the gap, driving technology from the bottom-up instead of the top-down.

Business-supplied requirements often lack quality attributes or non-functional requirements like availability, performance and security. These are either assumed or difficult for non-technical people to articulate and architects are the best equipped to specify these.

Architects need to listen more than they talk, learning as much as they can about the business context of their work and its business value. Drilling into requirements is a good start, helping to understand requirements’ context, assumptions and priorities. There is no point where an architect understands everything, only a process to continually learn.

While it is tempting for a newly appointed architect to focus on their pet technical problems, ensuring they have a good pipeline of requirements helps architects to align their efforts to solve others’ problems, not just the ones they perceive. They also need to ensure the business outcomes are met, not just the technical enhancemnts.

Looking at it another way, a design is not just a model (approximation) of the implementation. A design is the requirements for the implementation. Like requirements gathering, design is iterative and may change through the review or implementation process. Like requirements gathering, design is a trade-off. Like requirements gathering, it is an abstraction, leaving some details to implementers. If an architect cannot understand or provide good requirements, their designs are going to be misunderstood, at best, or ignored, at worst.

Moreover, architects are leaders. Not leaders in the management sense but leaders by collaboration, communication and example.

While the technical leadership of architects is well understood, good architects move out of their comfortable technical conversations and into the less comfortable business conversations. As mentioned above, some requirements sit between the technical and business and stakeholders need assurance the system will meet their needs. No design pattern or notation will achieve this.

Architects should focus on outcomes and end-to-end systems, not the minutiae of their designs, particularly in agile environments where just-in-time design occurs or where component responsibility is delegated to teams. Trusting implementors by giving them clear interfaces, scope and direction is the best way to foster their trust in architects.

Architects must own their communication. The responsibility for implementors and stakeholders understanding the design and vision rests with the architects. A design or vision that is not communicated is not understood and an architect producing designs no one understands has zero business value.

An architect must also facilitate communication between teams, particularly when design changes ripple through other teams’ work.

Architects must be accountable for systems they architect. They need to listen to implementors to understand their challenges and how to mitigate them in current or future designs. They need to accept criticism from stakeholders when requirements are not met. They also need to be applauded when their projects or systems succeed.

While designs are the architect’s deliverables in many projects, an architect’s success is driven by their ability to ensure they are solving the right problems and assure people of that direction. Good architects look down toward the technical detail and ensure it is correct. Great architects also look up and around to understand how they can best provide value to the business, sometimes better than the business can.

Image from https://www.flickr.com/photos/highersights/6231641551. Used under creative commons license.

Architecture, Software Architecture , , ,

Theresa May vs Encryption vs Solutions

Leave a comment Posted by on June 7, 2017

Theresa May

Theresa May’s speech in response to the recent terrorist attacks in London have, once again, mentioned cracking down on cyberspace “to prevent terrorist and extremist planning” and starving “this ideology the safe space it needs to breed.” World leaders, including Australia’s prime minister Malcolm Turnbull supported her, saying US social media companies should assist by “providing access to encrypted communications.”

Cory Doctorow and others make valid points about how impractical and difficult these dictates are to implement. Politicians mistakenly assume that weakened encryption or backdoors would only be available to authorized law enforcement and underestimate how interdependent the global software industry is.

However, presenting this as a binary argument is a “sucker’s choice”. Law enforcement is likely concerned because it cannot access potential evidence they have a legal right to see. While same laws arguably impinge personal freedoms, is it technology’s or technologists’ role to police governments?

Meanwhile, modern cryptography protecting data cannot also allow law enforcement access without weakening it. Consequently, technologists lambast politicians as ignorant and motivated by populism, not unreasonable considering Brexit and similar recent political events.

As technologists, we know what technology can and, more relevantly, cannot do. While it defines short term options, our current technology does not limit options in the long term. The technology industry needs to use the intelligence and inventiveness it prides itself on to solve both problems.

I do not know what forms these solutions will take. However, I look to technologies like homomorphic encryption or YouTube’s automated ability to scan it’s nearly uncountable number of videos for copyright infringements. There is certainly challenge, profit and prestige to be found.

The threat of criminal or terrorist action is not new. Mobile phones, social media and other phenomena of the digital age grant them the same protections as everyone else. Dismissing solutions from the ignorant does not mean the underlying problems go away. If the technology industry does not solve them, politicians may soon do it for them and, as Cory Doctorow and others point out, this will be the real tragedy.

Image credit: https://www.flickr.com/photos/number10gov/32793567693

Op-Ed , , ,

Floundering in Alphabet Soup Part I

Leave a comment Posted by on June 6, 2017

Alphabet SoupThe IT industry is swamped by certifications. Every conceivable three-, four- or five-letter acronym seems to mean something. However, everyone can recount a story of someone certified but clueless. In a world where answers are often a quick Internet search away, are certifications still relevant?

Certifications aim to show someone knows something or can do something, like configure a device or follow a process. Condensing a complex product, process or industry into a test is hard. Schools and universities, dedicated to learning with larger budgets, have been grappling with this for some time and even multi-year degrees are not always good predictors of competence.

Knowledge atrophies and conditions change. While some certifications require periodic certification or ongoing training to keep candidates current, there is no way to guarantee someone maintains or improves their skill and their knowledge is current.

Certifications risk devaluing experience. For example, the Microsoft Certified Systems Engineer (MCSE, now Solutions Expert) boot camps of the 1990s saw many inexperienced candidates spoon fed the minimum information to pass then unleashed on an industry expecting people more capable. Why hire someone experienced when you can hire a newly minted MCSE at a fraction of the price?

Certifications are no longer the only way to demonstrate competence. Speaking opportunities at user groups, social networks and blogging are open to anyone. Online training websites like Coursera or Pluralsight provide similar or identical material to common certifications at no or minimal cost. For a more specific example, a software developer that wants to demonstrate competency in a library or programming language can contribute to open source software or answer questions on Stack Overflow.

Many candidates complain about excessive certification costs, particularly for not-for-profit certification bodies. Certifications are expensive to create and administer, particularly minimizing cheating, and to market, because an unknown certification is wasted.

Does that mean certifications are dead? No. Certifications continue to have the same benefits they always had.

Certifications give you credibility. While saying you know something is easy, becoming certified is a known, third-party verified benchmark. Harder, time-consuming and/or hands-on ones like the Cisco Certified Internetwork Expert (CCIE) or Offensive Security Certified Professional (OSCP) especially so. They are good personal development goals.

Certifications make you more marketable. Many employers look to them as shortcuts for skills. Hiring someone certified decreases risk. Couple with experience or aptitude, they may lead to increased pay or new positions. They can even be a personal brand. For example, putting a certification next to your name on LinkedIn immediately tells the viewer your career focus.

Certifications open new networking opportunities. Certifications identify people with common interests or solving similar problems. Meetups, conferences and training courses target these. Some give discounts to certification holders, too.

Certifications tend to give rounded and broadly applicable knowledge, including different technologies, business areas or perspectives. They usually reference authoritative information and cover best practice, albeit sometimes abstracted or out of date. This can be harder to Google for because it requires domain knowledge.

Certifications benefit certifying authorities, too. From a vendor’s perspective, certification programs ensure product users are competent by requiring partners and resellers to have certified staff. Periodic recertification or certification expiry forces users to be up to date and creates recurring revenue.

The existence of certifications indicates a product’s or market’s maturity. They can help standardize, unify or legitimize a fragmented or new discipline. Certifications are as much a marketing tool as technical.

They allow vendors to identify and communicate directly with the user base. Vendors often know their customers (who is paying for the software) but not the people using it.

Certifications are not going away and are still relevant for the same reasons they always have been. They can still be a differentiator and misconstrued. They are still useful to vendors but expensive. However, the real question is how the current alphabet soup needs to evolve and still be relevant in the constantly changing IT landscape, particularly for areas like software development with a poor certification track record. That is something for the next blog post.

Image credit: http://www.flickr.com/people/bean/. Usage under CC BY-NC 2.0.

Op-Ed , ,

Rebranding Corporate Politics

Leave a comment Posted by on January 16, 2017

politicsThe term “corporate politics” conjures up images of sycophantic, self-serving behavior like boot-licking and backstabbing. However, to some IT professionals’ chagrin, we work with humans as much as computers. Dismissing humans is dismissing part of the job.

The best way to “play” corporate politics is solve big problems by doing things you enjoy and excel at.

“Big problems” means problems faced not just by your team but by your boss’s boss, your boss’s boss’s boss and so on. If you don’t know what they are, ask (easier than it sounds). Otherwise, attend all hands meetings, read industry literature or look at your leaders’ social network posts, particularly internal ones.

This is not just for those wanting promotions into management. Individual contributors still want better benefits and higher profile or challenging projects. These come easiest to those known to be providing value and not the strict meritocracy some IT professionals think they work in.

Start by solving small problems as side projects. Choose something impacting more than your own team and minimize others’ extra work. Build up to bigger problems once you have demonstrated ability and credibility.

You need not be the leader. Assisting others making an effort can be just as effective. You can own part of it or bask in the halo effect. If not, recognize those that are. This creates a culture of recognition that may recognize you in the future.

While some IT professionals solve big problems everyday, communicating and evangelizing their work “feels” wrong. This what salespeople do, not IT professionals. Many also think their work is not interesting.

Being successful requires people knowing what you do. This may be as simple as a short elevator chat, a brown bag talk or a post on the corporate social network. It also helps get early feedback and build a like-minded team. Others will be interested if you are working on the right things.

What about the potentially less savory aspects of corporate politics like work social events, sharing common interests with management, supporting corporate charities and so on? These are as much an art as a science. Focus on common goals and building trust, internally and externally. People like to deal with people at their level and contact builds familiarity.

However, this is no substitute for solving big problems. If you are delivering value, interactions with senior decision makers and IT professionals with similar goals should occur naturally. Build on that.

Be aware that problems change over time. Problems get solved by others. The market changes. Competitors come and go. Understanding organizational goals is an ongoing process.

Also realize decision makers are human. They make mistakes. They want to emphasize their achievements and not their failures, just like software developers’ fundamental attribute error bias for their own code and against others’.

However, if your organization makes decisions regularly on “political” grounds, leave. Culture is rarely changed from the ground up and many organizations are looking for good IT staff.

Ignoring the worse case scenario and IT professionals’ bias against self evangelism, the biggest problem with “corporate politics” is actually its name. The concepts behind “agile” and “technical debt” came into common usage once the correct metaphor was found. Corporate politics needs rebranding from something avoided to a tool that IT professionals use to advance themselves. It badly needs a dose of optimism and open mindedness.

Image credit: http://thebluediamondgallery.com/p/politics.html. Usage under CC BY-SA 3.0.

Information Security, Op-Ed, Software Architecture, Software Development , , , ,

InfoSec: Not just for hackers

Leave a comment Posted by on January 8, 2017

everybody-needs-a-hackerI recently read Troy Hunt’s blog post on careers in information security. Troy makes good points about information security as a potential career and the benefits of certifications like the Certified Ethical Hacker. Hackers are getting increasingly sophisticated, requiring specific knowledge to counter, and cryptography is hard. We need more information security specialists.

However, one criticism of the post, indeed the information security industry, is its implication hacking is the sole information security career path. This binary viewpoint – you are either a security person or not and there is only one “true” information security professional – does more harm than good.

Hacking is technology focused. However, security’s scope is not just technical. Information security needs people that can articulate security issue impact, potential solutions and their cost in terms non-security people can understand. This requires expertise and credibility in multiple disciplines from individual contributor level to management to boardrooms.

Security solutions are not just technical. We live in societies governed by laws. These can be standardized government security requirements as FedRAMP or IRAP. These can be contractual obligations like PCI-DSS, covering credit card transactions. These can hold organizations accountable, like mandatory breach disclosure legislation, or protect or privacy, like the European Union’s Data Protection laws. Effective legislation requires knowledge of both law and information security and the political nous to get it enacted.

We are also surrounded by financial systems. Financial systems to punish those with weak security and reward those with good security will only evolve if we (consumers and investors) value security more. Cyber insurance has potential. Cryptographic technologies like bitcoin and block chain algorithms are threatening to disrupt the financial sectors. Information security has and will continue to impact finance.

The list goes on. Law enforcement needs to identify, store and present cybercrime evidence to juries and prosecute under new and changing laws. Hospitals and doctors want to take advantage of electronic health records..

The security technology focus drives people away non-technology people. In a world crying out for diversity and collaboration, the last thing information security needs is people focusing solely inward on their own craft, reinforcing stereotypes of shady basement dwellers, and not on systems security enables.

Bringing this back to software, many organizations contract or hire in information security experts. Unfortunately, the OWASP Top 10 changed little from 2010 to 2013 and some say is unlikely to change in the 2016 call for data. According to the Microsoft Security Intelligence Report, around half of serious, industry wide problems are from applications. Developers make the same mistakes again and again.

Education is one solution – security literate developers will avoid or fix security issues themselves. A better solution is tools and libraries that are not vulnerable in the first place, moving security from being reactive to proactive. For example, using an Object-Relational Mapping library or parameterized queries instead of string substitution for writing SQL.

Unfortunately, security people often lack skills to contribute to development and design beyond security. While information security touches many areas, information security expertise is not development (or networking or architecture or DevOps) expertise.

Information security needs different perspectives to succeed. As Corey House, a Puralsight author like Troy Hunt says in his course Becoming an Outlier, one route to career success is specialization. Information security is a specialization for everyone to consider, not just hackers.

Image credit: https://www.flickr.com/photos/adulau/8442476626

Information Security, Op-Ed, Software Architecture, Software Development , , , , , , ,

Systems > Goals

Leave a comment Posted by on January 1, 2017

systems-over-goals

It is the time of year when people evaluate their previous year’s goals and plan for the next. It is the time when New Year’s resolutions are made. It is also the time where people lament ones they failed to keep.

Setting goals is beneficial. They are how we demonstrate commitment and achievement. They motivate us to better ourselves.

Take learning a new skill, like a programming language or library. This requires acquiring tools, reading or watching tutorials and/or working with teachers then practicing the new skill until proficiency is reached.

People approach goals in different ways. For example, learning the basics of a new programming language can be crammed into a weekend, fitting into our “busy” lives and short-term focus.

This may be sufficient if the need is urgent. However, this is not possible with larger or sustained goals.

A few years ago I realized I needed to lose weight. Superficial attempts at exercise or the occasional healthy meal were insufficient. I needed a sustainable system not just reach an arbitrary weight target.

First, I had to want to lose weight. There is a difference between imagining oneself attaining the goal and the often underestimated effort required to achieve it. For example, in his book “The Element”, Ken Robinson compliments a keyboard player saying he’d love to play the keyboard that well. The keyboard player disagrees:

“You mean you like the idea of playing keyboards. If you’d love to play them, you’d be doing it.”

Second, I had to create a system that would make me succeed: “No excuses!” My schedule was unpredictable so gym memberships and other organized activities were out. I had always enjoyed running so I purchased a treadmill. Diet was solved by subscribing to a calorie- and portion-controlled food delivery service. I enjoyed running and the food so it became almost harder not to follow the plan.

Third, I had to make time to exercise and the discipline to stick to the diet. My unpredictable schedule meant a exercise a regular times was not possible. I fell back to priorities: other things had to fit around exercise like Stephen Covey’s big rocks analogy.

Fourth, I weighed myself morning and night to track progress. Many weight loss programs recommend weighing less frequently but, as long as the downward trend continued, the raw measurements were less important than the accountability – the scales were always there looking back at me and never lied.

Yes, I occasionally ate too much or missed a run or three but I just picked myself up and resumed. Patience and persistence conquered the dreaded weight plateaus.

I eventually reached my target weight and celebrated my success. I lost a quarter of my body weight over eight months.

More importantly, I developed habits for keeping my weight down and increasing fitness. Reaching my target had become both inevitable and irrelevant. I kept going afterwards. A year later I ran a sub 96 minute half marathon. During lunchtime at work. For fun.

Without realizing it, I stumbled upon thinking about achieving as systems or habits, like in Charles Duhigg’s “The Power of Habit: Why We Do What We Do in Life and Business” or Scott Adam’s “How to Fail at Almost Everything and Still Win Big”. Goals are only milestones. Systems or habits allow you to achieve them.

I now look at goals differently. First, is the goal important enough to change my habits? I cannot do everything. I try to pick what I will fail at or others will do it for me.

Second, do I want the goal enough to change my habits? I try to separate what I want from what others want. Failing that, I look for sources of fun or rewards for doing so. Motivation is half the battle.

Op-Ed

The Potential of Cosmos: Containers

Leave a comment Posted by on December 16, 2016

cosmos-potential

Cosmos is an operating system construction kit in development since 2006. At first glance, it appeals to the “Internet of Things” (IoT) crowd. One could control home automation or run a Raspberry Pi or Arduino in C#. Cosmos is also interesting technically, as Scott Hanselman describes. .Net languages are rarely used for lower level programming and this project is an interesting case study.

However, there is a whole other angle to consider – a competitor to containers. Containers, single-application virtual machines, provide the hardware independence of virtual machines but are smaller and use an operating system’s existing isolation and switching mechanisms instead of a hypervisor.

If Cosmos or a system built on it supports a reasonable set of APIs, such as an early version of .Net Standard, these could be run like containers. The components and functionality would be minimal, reducing the surface area of attack and the need for patching. They could be smaller than scratch containers because they are a single binary.

A Cosmos container, for want of a better term, could run on bare metal for maximum performance. It could also run as a “pico virtual machine”, needing only a few MB of RAM and storage, to minimize costs.

Of course, there is more to containers than just the image format and hosting engine. Docker, the most common container engine, has a whole ecosystem of orchestration, management and monitoring tools. Many of these are open source and have high contribution rates, so adding Cosmos container support is not unreasonable.

Supporting Cosmos containers directly on hardware may require hypervisor changes, meaning existing IaaS vendors would not initially support it. That said, Amazon does support Arduino as a cloud platform. Cosmos containers could also run in a “serverless” compute service like AWS Lambda.

Of course, the Cosmos team have spent a long time bringing their original vision to fruition and this is a significant change in direction. However, we live in a world of potential where software is changing so quickly and is often open for anyone to build on.

 

Op-Ed , , ,

← Older posts

Newer posts →

%d bloggers like this: