Feeds:
Posts
Comments

Posts Tagged ‘technology’

The book Creative Selection by Ken Kocienda was recommended to me. This is unusual in that I’m typically the one recommending books to others.

This book follows the creation of the iPhone as seen through the eyes of the author, who was a software developer at Apple at the time. There are many interesting aspects to his story, to his interactions with the movers and shakers within Apple including eventually with Steve Jobs, and to the creative dynamic that made the iPhone possible at all.

Over the years, I’ve had the opportunity to participate in the world of Apple’s alpha and beta hardware, as well as that of many other technology firms as an engineer at firms working with Apple. I’ve also been on the other side of the fence, designing, developing and managing hardware and software, and their associated beta programs. It’s a challenging environment.

I’ve also had the opportunity of presenting my work to those holding the levers of power who had, shall we say, a less than gentle manner of showing disapproval with those thing not meeting with their standard of quality. There is an interesting combination of exhilaration and dread surrounding such presentations.

Elaborating on the details of the book in this post wouldn’t serve to encourage the would-be reader. If you are a follower of the history of Apple or technology, you’ll find things that will expand your view of the period and the dynamics surrounding it. You should also come away with a bit of insight into how Jobs looked at features. At least within the scope of the work that Kocienda presented him.

As a first outing, Kocienda does a reasonable job of painting a picture of the time and place that was Apple before they changed the world of mobile phones. The book is illustrated, which is unusual in a day and age of contemporaneous photography. I can’t imagine there not being numerous of photos from the proto-iPhone during its gestation. The pace of the book is decent and he conveys a sense of presence in the narrative. I felt that it could have been tighter, although that would have reduced the already roughly 200 pages of prose even further.

All-in-all, the book is well supported by references and is approachable by those not of the software tribe. You should be able to dispatch this one in a few hours. It’ll be joining my other volumes on the history of technology of this period.

 

Read Full Post »

As someone in the technology sector, on a fairly constant basis I get asked the grown-up equivalent of “what do you want to be when you grow up.” This is, of course, “where do you see yourself in N years.”

Now, most of the time, this is a question with all the gravity of “nice day, isn’t it?” Sometime, however, the inquiry is sincere. And my answer is provided with the same weight as the question.

And, for reference, my answer hasn’t changed all that much since I was about seven. Happily, the way that I answer has become a bit more sophisticated. My end game position is that of CTO (Chief Technology Officer).

Many of my contemporaries have gone the route of management. This is cool with me. You shouldn’t be doing engineering and science if you don’t have it in you. By in you, I intend the sense given by The Oracle in The Matrix when she told Neo that you know that you’re the one when you feel it “balls to bones.” Seriously. There are far easier ways to make a decent living than the constant demands and uncertainty that comes along with the endeavor of technological advancement. Hell, forget advancement, just using technology is a hard slog.

For me, working with technology and constantly expanding the reach of my understanding within that sphere is one of my core drives.

So like anything else I’ve ever set as a goal, I researched this thing I’ve set my sights on.

Let’s unwrap what I understand today.

It’s relative new

As C-suite positions go, the CTO is really young. Only the CISO (Chief Information Security Officer) position is newer. As you’d imagine it’s not like there weren’t technology companies before CTO roamed the Earth. Prior to recognizing that the technology landscape was changing so quickly and on such a continual basis that a board-level position focusing exclusively on the implications of such change, technology was the domain of either the CIO (Chief Information Officer) or CEO (Chief Executive Officer).

There was a realization that technology falls into two broad categories: present and future. You can think of these as tactical (product development) and strategic (futures research). Investopedia says that a CTO “examines the short and long term needs of an organization, and utilizes capital to make investments designed to help the organization reach its objectives … [the CTO] is the highest technology executive position within a company and leads the technology or engineering department.”

This division of labor is not unlike the was that Computer Science became an independent discipline. It too is dual-rooted. There were schools where the computer (singular) was managed by the Math department and those managed by the Electrical Engineering department. You can tell the difference in the focus in curriculum. It will be either theoretical (math) or applied (engineering) in nature.

It’s not only one

The position of CTO is in no way one-size-fits-all. Presently, it’s possible to identify four distinct sub-species of CTO. This diversity reflects the nature of the companies and how technology fits into their culture and mission.

We can identify these four by where the fall on the spectrum described by amount of business change and percentage of products and services based on information.

 

CTO quadrants

As can be seen, these are four very different animals. This is why you would expect the CTO from a relatively stable business in the manufacturing sector like GE (big thinker) to be very different from one at a business experiencing near constant change and highly-dependent on information in its products like Facebook (visionary). Neither of those would look anything like the stable business, high-dependency Apple (external-facing) or high change, low-dependency AT&T (information manager).

The Infrastructure Manager

CTO quadrant - infrastructure manager

 

Typically seen in companies with low dependency on information-related technologies, but with business models experiencing large amount of change (technology change impacting how the business is run), the Infrastructure Manager CTO reports to the CIO and is responsible for addressing how to build out and leverage technology to reduce cost and encourage technology adoption across business units in order to gain efficiencies.

The Big Thinker

 

CTO quadrants - big thinker

The Big Thinker CTO is the response to never-ending growth of things utilizing information technology. We see this type in companies with stable business models and a relatively low dependence on information as a part of their products. We see their focus on strategic initiatives such as:

  • Advanced technology
  • Competitive analysis
  • Technology assessment
  • Prototyping
  • Planning
  • Setting architectural standards
  • These CTO answer to the CEO and peer the CIO. Here we have a division of the IT and engineering departments. They act as change agents, typically having a relatively small elite staff. They are influencers rather than controllers.

The Visionary and Operations Manager

 

CTO quadrant - visionary

In companies in the throws of business change (increased technology complexity) and highly dependent upon information in their products and services, the CTO will be the Visionary and Operations Manager type. Answering to the CEO, this is the prime mover of the company. Their responsibilities are all encompassing. They drive business strategies and exploit new technologies and then implement those same technologies throughout the business and product groups. We see the CIO reporting to the CTO in this view of the world.

The External-facing Technologist

 

CTO quadrant - external technologist

Information-driven companies with stable business models will tend to have the External-facing Technologist CTO. As with the Big Thinker type, this CTO peers the CIO with both answering to the CEO. Here the focus in on the identifying new technologies, exploiting them, and evangelizing them both in and outside the organization.

Areas of Impact

If we visualize the areas of impact for the four type, we can see the natural focus areas for each.

infrastructure managerbig thinkervisionaryexternal technologist

Observations

Greg Brockman, Stripe’s CTO, said that other CTO’s “viewed themselves as the facilitators of the technology organization. Sometimes this was about connecting senior engineers. Sometimes it was mentoring. … I realized the most important thing to do was to empower our engineers to make big changes and improvements.”

“It’s not a simple job to understand all the technology out there,” says Unisys Corp’s global CTO Fred Dillman. “Today the pace of change is so much faster, and businesses are becoming more and more dependent on technology. So the CTO is being asked to be the real expert in technology and understanding what technologies will affect the business in the future and help determine when and where to invest.”

My fit

So, where do I see myself in all this? Tricky question.

Honestly, it varies. As the Version Control Systems Architect at Metrowerks, I was evangelizing source code control. At The Altamira Group, I rocked the visionary thing. Most of my CTO-esque activities have fallen into the Big Thinker bucket. Researching futures and educating engineers and management is where I spend the bulk of my time.

Roger Smith noted that “[t]he significant role of technology in strategic business decisions has created the need for executives who understand technology and recognize profitable applications to products, services and processes. many companies have addressed this need through the appointment of a chief technology officer (CTO) whose responsibilities include:

  • monitoring new technologies and assessing their potential to become new products and services
  • overseeing the selection of research projects to ensure that they have the potential to add value to the company
  • providing reliable technical assessments of potential mergers and acquisitions
  • explaining company products and future plans to the trade media
  • participating in government, academic and industry groups where there are opportunities to promote the company’s reputation and to capture valuable data

Integrating these technology-based activities into the corporate strategy requires that the CTO nurture effective relationships with key people throughout the company. These include the CEO, members of the executive committee, chief scientists, research laboratory directors, and marketing leaders.”

Regardless of the specific needs of the organization, I’ll continue to strive to provide the best information in a timely fashion to those who need it.

References

 

 

Read Full Post »

Sometimes you can spend years trying to find a book that you can recommend to someone who’s asked you a question. My latest read, The Software Craftsman: Professionalism, Pragmatism, Pride is one such book. A recent volume in the Robert C. Martin book series, this volume by Sandro Mancuso is not what it appears to be. And that, is a good thing.

When you look at the other books in the Martin series (Working Effectively with Legacy Code, Agile Estimating and Planning, Clean Code, The Clean Coder, Clean Architecture, …) you see topics decomposed and methodologies expressed by which the title’s subject is achieved. That’s not what you get with The Software Craftsman. In my case, that was a very fortunate turn of events.

This is not to say that the journey of the software craftsman is not discussed. It is and in a reasonable amount of detail. But an equal amount of time is given to the ecosystem within which the craftsman practices. These parts of the book are not for the consumption of the craftsman or aspirant, but for the owners of the firms who employ (or should employ) them.

The book does well in describing the trials and tribulations of a member of the craft; from the point where they realized that they aspired to more than the dichotomy of coder / architect; to the creation of the volume itself. It lays bare this false dichotomy within the broader context of the entire point of software development. That being to produce value to the customer and income to the creator. Within that context, there is the easy path of whatever works and the hard path of building a thing that no only does what it is supposed to, but does it in a way which is both high quality and highly maintainable.

At it’s core, this is book about philosophy. In a landscape of Google and go; and compile it, link it, ship it, debug it; this is a thoughtful volume. It makes the point that I’ve never seen in print, that the individual software developer is responsible for their own career development. Not their manager, not their company, but they themselves are responsible. Heady stuff this.

As to the remainder of the book’s material, it’s more a wake up call to upper management. There you’ll find discussion of recruiting, hiring, retaining, shaping change and showing ROI. I know of very few who could look at this volume and come away unmoved.

It might be the separation of authority and responsibility, the hire for what we needed yesterday, the CYA so we get our bonus, or the factory worker mentality encouraged by so many firms today. If you can read this book and not get something out of it, you’re part of the problem.

Truly quality software is designed, built, and tested by passionate individuals working together toward the creation of something which will well serve the customer. Everything else is just code. Any 10 year-old can be taught to write code. I know, I’ve done it. Do you want your life’s critical systems to be build by 10 year-olds? Of course not, that’s a ridiculous question. How about people who are just doing it because they make a better than average day’s wage?

I hope you’re intrigued. At the very least, I hope you’ll reflect on your own views of the responsibilities of a software developer. At fewer than 250 pages, you can read this book in one or two sittings, but reading the book is only the starting point.

 

Read Full Post »

There’s been a lot of churn lately over the price of Bitcoin. There’s also been much talk about uses (commercial and otherwise) for the blockchain technology that underlies it. I’ve taken an interest, as of late, in the subject and I found a promising source of information in the Michael J Casey, Paul Vigna book The Truth Machine.

If you’re looking for a book on how to write blockchain software. This book isn’t going to be of much interest to you. If you have interest in the history of the technology, its applications and societal impacts, you will find it to be a solid read.

Bitcoin and  Ethereum, and the like are discussed with enough depth to provide non-developers a good sense of use cases. This is after all the point of a technology. Otherwise you’ve got yourself shelfware. All the major players are discussed running the gamut from crypto-anarchists to Wall Street bankers. I find the dynamic of these two extremes battling over this technology fascinating.

One definitely comes away with the sense that the technology is still very much a work in progress. Personally, I find it unfortunate that the public sees it as another get-rich-quick methodology. This loops back to the volatility of the Coin markets.

Another, and arguably more important, takeaway is that the systems currently in place do not scale (or at least have yet to be proven to scale). That Bitcoin can process six transactions per second in a world where Visa processed ten thousand is quite telling.

The underlying problem of who’s in charge comes to mind. Without some form of human governance, poor programming will result in bad actors taking advantage of the system. Nowhere does the book address the issue of longevity. The thing about paper (or animal hide for that matter) is that it has a permanence that has proven itself outside of our advances in storage technology. If we did move to a blockchain-based system of ownership tracking, what happens when another, better one comes along? What will the impact of quantum computing be in a world where work is proportional to CPU expended? What happens when people decide that it’s easier to steal the resources used to mine the coin?

I only have a few issues with the book.

First, for a book on a complex technological subject, I expect extra fact checking. I noticed two rookie mistakes in this department. ASIC is defined as ‘Application-Specific Integrated Chips’ whereas it should be ‘Application-Specific Integrated Circuit.’ It also doesn’t require quotes. In the realm of techno-history, the authors attributed Public-Key Cryptography to Whitfield Diffie and Martin Hellman. This is of course incorrect. That distinction belongs to James H Ellis (at least until the NSA owns up to when they started using it). Although his work was once classified, it have been publicly recognized for some time now.

Second, the book wanders off the path of techno-history and into the realm of  conspiracy theory and political opinion when they introduce ‘speculation’ of hacking in the MH370 incident and spend the bulk of the last chapter on the latter.

On the whole, I found the book to be a very good and current survey of the landscape of blockchain technology and its history.

 

Read Full Post »

The early years of computing were a like a Renaissance dance, lots of people who somehow manage to get to dance with each other at least once. A Mind at Play: How Claude Shannon Invented the Information Age gives us yet another place to stand and watch that dance.

Claude Shannon is one of those people who fundamentally changed the way we look at the world. The problem with fundamental change is that we tend to be on one side or the other of it. Today we speak of information theory as though it’s as obvious a concept as making paper. Kind of the same way we obsess over software developers being able to write code to sort numbers or reverse linked lists. At some point, the fundamental reality of the existence of high-quality libraries and data structures will make these queries as relevant as requiring people to explain a tape sort. But I digress.

He was a researcher, tinkerer, teacher, juggler, and for all appearances didn’t seem attached to labels. He had Vannevar Bush looking out for him. As an MIT professor, he had Danny Hillis and Ivan Sutherland, among others, as doctoral students. He worked with Alan Turing during World War II. And the box-switch-thing that turns itself off. That was him.

Reading the book, you get a sense of possibilities explored. So often people either dismiss or defer possibilities. He literally had a basement full of them. If only he’d know Ron Popeil, every home might have a few of them.

I don’t know how well he would fare in the world today. In his time, Bell Labs basically paid to have him around. He had cachet. He also helped focus people’s ideas. He brought this sensibility to MIT with him as a professor. We get so terribly wrapped up in being hyper-specialized, in know the what but not the why. To often we come across the proverbial Gordian knot and turn away. People are either unwilling to try, or believing themselves to be special, simply act as though the problem does not exist. (Treating people poorly and flaunting violations of the law fall into this category.) Few people are willing to question the fundamentals. What do you need? What do you have?

The interesting people are those who solve problems and help other people solve problems, not by merely telling them what the answer is, but by enabling them to see that solutions can come from places that aren’t necessarily rooted in the past ways of doing things.

In our day and age, when we focus on special skills and special languages and special hardware, it would behoove us to remember that there is no best skill or language or hardware. There is only the universe of problems. It is far more valuable to be able to help others see the shape of the solution than to be an individual capable of providing a answer to a well-defined question whose value will in time expire.

Read Full Post »

When I was asked to create and teach a Python class, I had to ask myself, “where is the starting point for this language?”

When it comes to computer languages, I like them logical, powerful, compact and fast. The language currently at the top of my list is Swift. When it comes to longevity, C++ wins hands down. Python is neither compact nor fast. It is, however, very popular. It’s also very flexible.

The C language has so many children that it’s easy to use analogs. What about Python?

I’ve taken intro CS courses from Harvard, Rice and Stanford all of which use Python. They all teach C programming in Python in my opinion. I get where they’re coming from. You’ve spent years using FORTRAN then Pascal then Java.

Happily, my first language was FORTRAN. You think you need to build all your own data structures if you use C. Consider yourself lucky. But that’s a story for another day. My second lanugage as APL. Go ahead try to teach APL the way you teach C. Knock yourself out. A bit later I picked up BASIC, which after FORTRAN was trivial. Next came Forth. That took a bit to wrap my procedural head around. My experience with APL had taught me that it’s perfectly fine to focus on the data and not the process. Forth’s focus on the stack is strangely intriguing. The fact that it lives on in UEFI and Postscript is a testament to the fact that there is value in that view of the world.

So my approach was to start with data representation. In Python the world is all objects and references. But for some reason, people don’t want to approach the language from that standpoint. They like to talk about how easy it is to write ‘hello, world’ programs or how it’s more readable than Perl. Aside from APL, I don’t know anything that’s less readable than Perl. Except maybe TECO macros.

Now that I had a place to start, life should be a hop, skip and a jump to classes, yes? Not so fast pilgrim. It’s easy to explain that everything is an object and that integers are a sub-class of rationals. It’s easy to explain that 0 takes 12 bytes of storage. You can even justify the lack of a character object. But I think you do a true disservice if you don’t address the fact that strings are Unicode based. I’ve dealt with enough internationalization issues to know that to gloss over this would be a disservice to the student. I probably spent more time working on the string section of my class than any other.

The reason? It’s one thing to present information that raises obvious questions like, “so you’ve told me that there as multiple ways to represent the same grapheme and that these strings will have different code units, but what am I supposed to do about it?” Or “how am I supposed to sleep knowing that a Vai 4 digit isn’t the same as an Arabic numeral 4?” You might as well throw them under a bus if you honestly believe that you’ve discharged your duty as a teacher by telling the students that there are land mines out there and that they should bring an umbrella. You’ve essentially just given them a compelling reason to never use the language.

Once all the ‘core’ data types are out of the way, it’s time for some core data structure like list, tuple, and namespace.

Functions, generators, and lambdas come next. These are relatively straightforward. The trick to generators is to show the equivalent implementation in C++. Yes, they are different beasts, but you can get close enough. Similarly with lambdas.

Now, you’re in a position where classes can be reasonably explained. A point to mention here is that back before embarking on a exposition of data types, keywords and variable conventions were addressed. Now, for most students, this goes in one ear and out the other. Having arrived at classes, all those naming conventions come back like an overeager Sheltie wanting to play. Ignore them at your peril. Enumerations are also introduced here.

For many, all the object bits will now come into focus. This is a good thing. I’ve never liked the approach where students are taught how to use bits and pieces of libraries without the foundation to understand what’s actually happening. They end up with a false sense of accomplishment and may never seek to build an accurate model of the languages world. They’re like Jeff Goldblum’s character in ‘The Fly’ having no clue how things actually work since he just specified what he wanted a given part to do and plugged the parts together. We all now how that worked out for him. It also emphasizes their importance of debugging you system.

I’ve never understood why some people shy away from classes in Python. They act as though organization is an inherently evil thing. They also probably have all their laundry in two piles in the middle of their bedroom (one dirty, one clean).

Classes point us to resource management, but we can’t do that discussion until input / output is covered. That gives us the idea of using classes (file streams) and their methods to process data. Here’s where string formatting and core data conversion comes in.

Up until now, exceptions have been alluded to. Now there’s enough structure to not only address, but give meaningful examples of their use.

At this point, you’re done with the core language. So we’ll address unit testing. We’ve done bits of this along the way since the introduction of classes, but now we can talk about the unit test library.

What remains are sections on sequence and associative containers. An important aspect of this is teaching how to select the appropriate container. Yes, you can use list and tuple alone, but there are better things to do with your life than reinventing the wheel. Technical interviews insisting that people be able to balance binary trees notwithstanding.

Finally, a brief introduction to the standard library. Before Googling, how about being aware what’s already in the box.

You’ll note a distinct absence of web browsers, GUI applications, client-server systems, etc. Just the language here.

Would my class make you a Python expert. By no means. As with all things, you become proficient through years of study and practice. It is my hope that my Python class would give you a good start on that journey.

Read Full Post »

I’ve just finished reading Code Warriors: NSA’s Codebreakers and the Secret Intelligence War Against the Soviet Union by Stephen Budiansky. It tells the story of the US National Security Agency (NSA) up through the end of the Cold War.

Given the number of dry histories of the people and agencies who deal with cryptography and spying, this book is reasonably readable. If you’re looking for a less arch, and more human view on how things got to where they are; you’ll like this book.

The takeaway from the book is that the biggest hindrance in the world of security is people. People who are control freaks or don’t believe that rules apply to them, or believe that the “other side” is stupid, or are just too damn lazy to do the simple things that would avoid issues are the problem. You can’t design your way around them. If you try, you’ll only make things worse.

You can’t pretend you have the moral high ground when you’re collecting enough information to make the US National Archives, the Library of Congress, Google and Facebook look redundant. I’m not picking sides, I’m just saying that if you’ve got a hammer and you use the hammer, own up to the fact and don’t go around telling everybody and their brother that they shouldn’t use hammers and that in fact that hammers either don’t exist or are illegal (or would be if they did actually exist, which they don’t).

Along the way, you’ll be introduced to a cast of well-intentioned, clueless, brilliant and ruthless individuals. There are miscommunications, denial of responsibilities, bruised egos, moments of insight and face palm moments.

Please keep in mind Hanlon’s razor.

 

Read Full Post »

I’ve finished reading The Shadow Factory (James Bamford) [Hardcover] – a history of the US intelligence community’s (especially the NSA) actions post 9/11.

 

Read Full Post »

I finished reading two books this weekend:

Read Full Post »

%d bloggers like this: