2019-07-24

2019-07-24 Wednesday - Updated Artifact Classification Codes - A Taxonomy

A pretty significant update, restructuring, and clean-up

https://github.com/intltechventures/Consulting.Project.Tools/blob/master/taxonomies/ClassificationCodes.md

Still rough, and still a working draft - but  just approaching a level of usefulness as a starting point that a team could customize to their needs.
Posted by No comments:
Labels: , , , , , , ,

2019-07-20

2019-07-20 Saturday - The 10x software engineer

Photo by Nicolas Hoizey on Unsplash

There is an assumption embraced by many in the field of software engineering - that may take the form of one of two diametrically opposed positions:
  • 10x software engineers exist.
  • 10x software engineers are a myth.
I'm interested in the arguments put forth by both camps. However, in every field of endeavor, there are exceptional, world-class, elite performers. To deny that fact - would be foolish.
But first, let me explain something. The reason for writing this is actually two-fold:
 1) I'm interested in understanding WHY people hold either of these opinions.
2) if you think this is an important question - if you believe that you should be seeking out 10x software engineers in your hiring process -  permit me to to submit for your consideration - that you may be focusing on the wrong thing... (read this thread)

What you should be infinitely more concerned about - is rooting out the [-10x] software engineer from your organization.
Let me explain.
Drawn from over 30 years of observations while working in the industry - here are a few ideas of what might constitutes a [-10x] software engineer:
  • Some lack the minimum requisite skills, aptitude, and technical knowledge.
  • Some lack the interest/desire/motivation to make the necessary investment of time and effort to continue to maintain (and expand) their skills, knowledge, and professional development.
  • Some are unaware of the minimal basics of good software development practices.
  • Some are careless and inattentive.
  • Some create more technical debt - than value-add
  • Some focus on the easy ("window dressing") tasks first - delaying the hard work of eliminating technical risks/unknowns - putting the organization at significant risk of late discovery - and of incurring massive rework.
  • Some are too enamored with driving their solution design recommendations based on resume-driven technology decisions (aka "Shiny New Thing" addiction, or a variation of "Let's Gamble Whether The Business Survives with this Unproven Technology").
  • Some will willingly commit code to the source repository - that has not been tested. At all.
  • Some will argue that version control is an unnecessary burden.
  • Some will argue that writing documentation is an unnecessary burden.
  • Some will argue that they don't have time to write automated test cases.
  • Some lack an understanding of basic algorithms and data structures - and therefore are unqualified to make most nontrivial design decisions. 
  • Some seem to take joy in creating an atmosphere of negativity and fomenting dissension.

Such individuals are capable of [-10x]  damage to an organization - they should have their network access revoked, and should be escorted from the building.

A client once engaged me in an architecture mentoring role - to help assess a very large engineering team (> 100) - to help diagnose why they were creating more technical debt - and more defects - in every Agile Sprint - than Stories delivered (by a not insignificant multiple).  My conclusion - after a significant amount of code inspections and code review discussions - was that quite a few of those software engineers were definitely in the [-10x] category.

As I explore my own thoughts on this topic - I will come back periodically and elaborate more in this posting, but I do have a few initial thoughts that may help illustrate where my views may diverge from what has previously been written by others.

If there are such things 10x software engineers - I think the distinction is really about the magnitude of the impact that a software engineer has beyond the scope of just their own work.
 
For your consideration - possible key indicators that someone might be a mythical 10x software engineer:
  • A 10x software engineer demonstrates an active awareness and appreciation for the efficiency and productivity of their team - and their organization.
  • A 10x software engineer isn't necessarily the engineer that codes 10x more, or 10x faster - but may be a more subtle and nuanced value proposition - in that the 10x person makes smarter choices - that result in code that is:
    • more extensible; 
    • easier to maintain; 
    • easier to understand; 
    • is well tested; 
    • demonstrates elegance; 
    • shows keen insight in the naming of things; and,
    • exhibits higher scalability and performance tolerances.
  • A 10x software engineer focuses on eliminating technical risks/unknowns first - so that late discovery is mitigated - and reduces the potential need for massive rework.
  • A key indicator of a 10x software engineer is demonstrated by their relentless efforts to educate, elevate, and improve the abilities of other engineers in the organization.
  • A key indicator of a 10x software engineer is their intense focus on automating the mundane - so that processes are automated, less error-prone, of higher quality, repeatable, and frees not just them - but their team/organization - to focus on more value-added work.
  • A key indicator of a 10x software engineer is their ability to intuitively "see" (or, know) how a design will perform under various stress conditions - before writing a line of code.
  • A key indicator of a 10x software engineer is their judicious application of this rule: "The fastest code is the code that you don't need to write".
  • A key indicator of a 10x software engineer is in the ability to align their intuition, brilliance, creativity - with their efforts to create software - such that their design expands the capabilities of the organization in new dimensions - both in terms of business services offered, revenue generation, cost reduction, and enabling new business opportunities.  
  • A 10x software engineer is humble and works to lift and elevate the capabilities (and attitudes) of their colleagues - and brings a tremendous positive energy to the work that they do - that permeates their environment.

I have more thoughts on this - but will do some deeper reading and reflection before returning to my key indicators list discussion above.

Fundamentally - I do believe - that there are individuals that exhibit better awareness, bring such a greater depth and breadth of experience, have a higher level of intuition, are more meticulous in their attention-to-detail, exhibit an extraordinary Duty-of-Care, deliver a higher quality in their work products, produce code with much better performance, who build software with better efficiency, and who make better design choices - and their contributions are so material and substantial - that they can have a positive 10x impact on an organization.
Thus, I agree that there are 10x software engineers - for I have seen firsthand the carnage and devastation that even a modicum of [-10x] software engineers can inflict on an organization - and I have been fortunate to have worked with several software engineers who were certainly worthy of the 10x designation - by virtue of the indicators noted above.

Perhaps 10x is a misnomer. Certainly no one performs at peak performance, all the time.
Perhaps a 10x is really more of a [1:10], or a [1:20], or a [1:100].

Background Reading:
Scholarly Research:
1984:
2002:  
  • An investigation into the effects of code coupling on team dynamics and productivity, Proceedings 26th Annual International Computer Software and Applications (August 2002)
    • "During the past three decades a number of theories have been proposed to explain the idiosyncrasies of software development as a team activity. The paper compares and combines these theories into a coherent model of software development that links software coupling and dependency management with team productivity. As a practical test of this model, the paper then investigates, the effects of coupling in two large commercial systems. It achieves this by using the VCML Views visualisation technique, developed by the authors, to expose the system wide coupling found in the code and how this coupling develops during the lifetime of a project. It then compares the resultant VCML views with simple attributes of the two projects to derive a set of important conclusions. In particular, it finds that unmanaged coupling within the code is a good indicator of potential productivity bottlenecks; that the number of programmers on a project is not necessarily a good indicator of programmer productivity; and that the architecture of a software system can radically alter the number of programmers that can effectively work together on a system."

2006:
  • Pair programming productivity: Novice–novice vs. expert–expert, International Journal of Human-Computer Studies Volume 64, Issue 9, September 2006, Pages 915-925
    • "Agile Software Development methodologies have grown in popularity both among academic researchers and industrial practitioners. Among the various methodologies or practices proposed, pair programming, which is concerned with two programmers collaborating on design, coding and testing, has become a controversial focus of interest. Even though some success stories have been reported with the use of pair-programming in real software development environment, many people remain rather skeptical of the claims on pair-programming productivity. Previous studies in pair programming have only addressed the basic understanding of the productivity of pairs and they have not addressed the variation in productivity between pairs of varying skills and experience, such as between novice–novice and expert–expert. Statistical productivity measurements reported by different researchers also seem to lead to contradictory conclusions. Until now, the literature has not addressed how those results and experiments were related to each other. In this paper, we propose a controlled experiment called repeat-programming which can facilitate the understanding of relationships between human experience and programming productivity. Repeat-programming can be performed when controversial issues in non-traditional programming methodologies and development productivity need to be investigated into. To illustrate how the proposed empirical experiment can put arguable, divisive problems into perspective, we have examined the productivity in pair programming as a case study. With repeat-programming, we are able to (i) better understand why results of previous pair programming control experiments reached different conclusions as to the productivity of pair programming and (ii) most importantly, present a case in which novice–novice pairs against novice solos are much more productive than expert–expert pairs against expert solos."
 2007+: 
 2012: 
  • MEASURING PRODUCTIVITY OF SOFTWARE DEVELOPMENT TEAMS, Serbian Journal of Management 7 (1) (2012) 65 - 75
    • "This paper gives an exhaustive literature review of the techniques and models available to measure the productivity of software development teams. Definition of productivity, measuring individual programmer’s productivity, and measuring software development team productivity are discussed. Based on the literature review it was found that software productivity measurement can be done using SLOC (Source Lines of Code), function points, use case points, object points, and feature points. Secondary research findings indicate that the team size, response time, task complexity, team climate and team cohesion have an impact on software development team productivity. List of factors affecting the software development team productivity are studied and reviewed."


 2014:
  • Software developers' perceptions of productivity, FSE 2014 Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering Pages 19-29
    • "The better the software development community becomes at creating software, the more software the world seems to demand. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In both studies, we found that developers perceive their days as productive when they complete many or big tasks without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices."
2016: 
  • What Predicts Software Developers’ Productivity? 
    • "Organizations have a variety of options to help their software developers become their most productive selves, frommodifying office layouts, to investing in better tools, to cleaning up the source code. But which options will have the biggest impact?Drawing from the literature in software engineering and industrial/organizational psychology to identify factors that correlate withproductivity, we designed a survey that asked 622 developers across 3 companies about these productivity factors and about self-ratedproductivity. Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors,such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to otherknowledge workers, our results also suggest that software developers’ self-rated productivity is more strongly related to task varietyand ability to work remotely."
 2017:
  • Pashkevich, Natallia and Haftor, Darek M., (2017). "SOFTWARE PROGRAMMER PRODUCTIVITY: A COMPLEMENTARY-BASED RESEARCH MODE". In Proceedings of the 25th European Conference on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017 (pp. 2755-2766). ISBN 978-0-9915567-0-0 Research-in-Progress Papers. 
    • "The identification of the factors that condition a software programmer’s productivity remains a key challenge for both scholars and practitioners. While a number of studies have focused on the impact of one or a few particular factors, the way these factors jointly condition programmer productivity is still unknown. This paper presents a conceptual model aimed at a comprehensive understanding of the factors that complement each other to govern the productivity of a software programmer. The model is based on complementarity theory and its systems approach and addresses an individual worker’s productivity, which accounts for cognitive, technological, and organizational characteristics. The analyzed factors are organized into a system of complementarities, offering two propositions that specify the conditions of a programmer’s productivity. The model’s key contribution lies in its unique configuration of two systems of complementarities, which have the potential to add to the literature on the productivity of software programmers. The proposed model can be employed as a guidance for the design of empirical investigations of the conditions of individual software programmers’ productivity as well as information worker productivity in general."
  • Chapter-4, Cooperative Software Development Andrew J. Ko with contributions from Benjamin Xie
    • "After teaching software engineering for many years, I've been frustrated by the lack of a simple, concise, and practical introduction to the human aspects of software engineering for students interested in becoming software engineers."
    • "In response, I've distilled my lectures from the past decade into these brief writings. They don't represent everything we know about software engineering (in particular, I don't discuss the deep technical contributions from the field), but the chapters do synthesize the broad evidence we have about how teams have to work together to succeed."

Misc. Articles, Blog posts:
This thread is illustrative of someone who has incredibly wrong ideas about 10x - and whose reasoning borders on cargo cult science...what he describes is prima donna behavior, at best...
 This thread (a response to the one above) is a much more sane exposition...
 Other articles founds...


Possible 10x Programmer Exemplars:

Exhibit #1: Fabrice Bellard: 
Exhibit #2: George Hotz



For the final answer to this question, Patrick Shyu's dry wit is excellent.
"Stack 10 keyboards" 
"Solve the problem forever and for everybody!"



One of the comments on Patrick's video wrote this brilliant gem:
"A 1x-er fixes a program. A 10x-er deletes the program."

 

2021-10-29 Friday

Forrest Brazaal: "10x developer" is meaningless without solving for X...

https://newsletter.goodtechthings.com/p/developer-equations

 



Posted by No comments:
Labels: , , ,

2019-07-19

2019-07-19 Friday - Polyverse.io (Polymorphic OS)

I am always keen to keep an eye out for new innovative approaches to improving the security of the enterprise.

Through my connection with Pete Jarvis, I recently learned about Polyverse.io


 The company has assembled an impressive team:

  • Alex Gounares, CEO:
    • Former CTO AOL, CTO Microsoft Online
    • Bill Gates Technology Advisor (TA) for four years 
  • Archis Gore,  CTO:
    • Winner of code for Bill Gates contest in India (150K+ applicants)
    • Ran site reliability and security for Amazon.com globally
  • Chris Hanaoka   Chief/VP of Engineering:
    • Ran Azure Cloud Infrastructure at Microsoft 1M+ servers
    • VP Engineering Yahoo
    • VP Engineering Ask.com
  • Steven Potter, VP Global Sales: 
    • $12B+ in government and commercial contracts awarded over his 20 year career
    • Army Invention of the year
    • Navy SEAL
  • Pete Jarvis, VP Business: 
    • Nortel Networks Presidents award for innovation for CentrexIP, 
    • Ran Microsoft UPnP Forum, 
    • Named contributor to WS-Security, WS-Eventing, WS-Discovery.
"Security is complicated, and companies often don't have the personnel or resources to protect themselves. Polyverse enables 'No Click Security', that protects you before, during, and after a fileless attack. It takes five steps to install and protect yourself. https://polyverse.io/polymorphic-linux-installation-guide/ and enables expansion of Splunk, Elastic and MicroFocus  ArcSight threat detection capabilities."
"What: Polyverse overcomes hacking by hiding operating systems in plain sight: where you have a million threats to one operating system, Polyverse provides millions of operating systems to one threat. We support public cloud, private data center deployments, and Arm, Intel architectures for embedded deployments."
"How: Polyverse inverts the problem, we take the OS and recompile it so each OS instance is unique at a memory and stack level. Polyverse's goal is to change the economics of attack in support of the defense. How so? Today, an attacker can invest 10 million in the creation of an exploit that takes control of an operating system. The attacker then recoups the investment across millions of devices, further once detected they will sell the exploit to others. Polyverse stops the first operating system investment being applied to the next. This breaks the economic model of attack. Polyverse consumes the resources of the attacker and stops them from recouping their time, and money across [N] devices."

"The Result: The attack is detected, thwarted and the attacker goes elsewhere."
"Status: Today, Polyverse works with the US Government, DLT, Microsoft, Amazon Web Services, MicroFocus, RedHat, Ubuntu, Alpine, and others to stop fileless attacks in the wild. Polyverse most notably does not change the source code of the operating system in any way, only the compiled binary operating system image layout. This approach drastically reduces the attack surface for the attacker, yet requires no changes to developer or user behavior."

"Detect, Defend, Deter: Here is a video overview of a simulated zero day stack attack on an OS, without and with Polyverse. In the case of with Polyverse the attack triggers a segmentation fault. Thus, we can deploy 10 instances – 6 standard, and 4 Polyverse instances and monitor the systems with Elastic, Splunk or Micro Focus ArcSight. If the four Polyverse instances seg fault, and the six standard do not we infer that a zero day exploit has been applied and notify the administrator."
https://vimeo.com/259728601
"Polyverse can be used to enhance your site detection capabilities in collaboration with Elastic, Splunk and MicroFocus to signal attack, and defend and deter attackers."
 Partnerships / Certifications:
  • Docker Member
  • Open Container Initiative Member
  • Red Hat Technology Partner
  • VMware Partner Ready for VMware Cloud on AWS
  • Open Invention Network Member

Pete shared some noteworthy penetration testing results from a real-world public security hackathon:

  • "None of the teams could to gain access to Polyverse VM's."
  • "Most people/teams would spend 20-30 minutes attempting to gain access, got frustrated and then moved on to the other VM's without Polyverse."
    • "Conclusion: The attacker saw a better door lock, and moved on to an easier target."
  • "Zero Polyverse customers have been remotely exploited by fileless attacks "

    Another interesting bit:

    Polyverse runs "the largest build farm for Linux in the world on AWS. (200K build jobs at any given time, 1M+ jobs at peak, 10 Complete Linux Distributions rebuilt twice a day for every machine.)"

    For those interested in more information, please contact Pete Jarvis, VP of Business, Polyverse:

    These YouTube videos may also be of interest:







    Posted by No comments:
    Labels: ,

    2019-07-18

    2019-07-18 Thursday - Quantum Physicist Prof Michelle Simmons - Breakthrough


    Quantum leap from Australian research promises super-fast computing power

    https://www.theguardian.com/technology/2019/jul/19/quantum-leap-australian-researchers-could-lead-to-much-greater-computing-power

    • "they have been able to achieve the first two-qubit gate between atom qubits in silicon, allowing them to communicate with each other at a 200 times faster rate than previously achieved at 0.8 nanoseconds."
    • "In choosing silicon, Simmons said the research team had demonstrated that their atomic-scale circuitry has the lowest electrical noise of any system yet devised to connect to a semiconductor qubit."
    Posted by No comments:
    Labels:

    2019-07-16

    2019-07-16 Tuesday - Thoughts on a recent CIO article

    CIO Article: What is Architecture?
    https://www.cio.com/article/3404327/what-is-architecture.html

    First, let me say - I find much that I agree with - in the views expressed by the author.

    However, I find the author's statements to be a bit incongruent in one respect - in that he acknowledges the value of creating architecture views/artifacts for particular users; to answer specific questions; the relevance of specific stakeholders; fit-for-purpose depictions, etc...

    ...to only then leap to a conclusion, which - as phrased - is not really supported by the preceding statements:
    ..."there are only two reasons to create any architecture artifact: to explain an engineering design to a non-engineer, or to mitigate technical risk."

    Here, something seems inherently "out-of-tune"...



    Taken at face value - this article, if embraced by non-IT executives - does a great disservice to  minimize the value of enterprise architecture efforts.

    I would submit that there may be other valid scenarios worthy of your consideration - for justifying the creation of architecture artifacts - that would otherwise be excluded by such a simple test.

    These are just a few examples that quickly come to mind:
    • To provide a mechanism for evolving (and aligning) the thinking of a proposed architecture - that can be communicated with technical and non-technical staff (e.g. for communication; for managing expectations, for iterative agile architecture evolution; for architecture ideation; for soliciting input - not necessarily to address a technical risk) - which requires both precise technical depictions, and often must necessarily include higher-level abstractions for consumption by non-technical / business stakeholders.
    • To communicate and coordinate architecture details with integration partners (whether internally, for communication with distributed teams across a corporation - or, with external third-party partners).
    • To support RFP processes - to provide sufficient detail for fixed-price quotes to be negotiated 
    • To support recurring periodic analysis for Application Portfolio Management (APM) Rationalization opportunities
    • To support Value Chain Analysis - and opportunities for rationalization and optimization.
    • To support Lean Process Improvement optimization. 
    • To support roadmap planning.  
    • To document an Architecture Decision Record (ADR), re: Agile Architecture
    •  To document the trade-off analysis when there are competing alternatives.  This creates a point-in-time perspective - but also is an invaluable tool in teaching business stakeholders, engineers - and in developing junior architects - by serving as an educating mechanism for the concerns that should be considered - how they are weighed - and how to balance competing concerns in making a final decision.  This also serves as a  "glue" function for improving communication & collaboration with the various stakeholder groups - and supports vetting that architecture has correctly heard (and understood) the key business priorities - and is not basing architecture decisions purely on the merit of technical considerations.
    •  To support communication and transition planning between AS-IS and TO-BE
    • To support Dependency Impact Analysis - to accelerate the ability of the organization to quickly & accurately determine where the modification or replacement of a given system (or component) may have upstream or downstream impact. [Ardoq is one example of an architecture tool that can be of significant help in such an endeavor.]
    • To provide a meaningful way to organize and capture "tribal knowledge" that might otherwise walk out the door, as staff turnover inevitably occurs. 
    • To clearly articulate the boundaries of responsibility between systems; and between automated vs. manual processes;
    • To support reviews by Security, Audit,  and Compliance/Governance processes - that are mandated by regulatory (or practical) considerations

    Where I fundamentally find myself in disagreement with the author,  may best be surmised as follows:
    • Architecture isn't just about technical risk mitigation, or just explaining the engineering design to a non-engineer.
    • Architecture is a holistic exercise that must include not only the engineering and technical aspects  of design - but must also consider and reflect the business goals and objectives - and an understanding of the technical/non-technical forces and constraints that may inform, constrain, and guide any solution design considered.
    • The architect's role in documenting a system must include an understanding (and representation) - of how value is created for the business - and by documenting the AS-IS, and via transition plan - move the conversation to focus on the TO-BE, driven by a business-valued focus on reducing costs, increasing FLOW - to reduce time-to-market for new products and services, and increasing operational efficiency.
    • Architecture is also about telling a story: To answer the important question of  "Why?"- as well as "Who", "What', "How", and "Where" (and sometimes, we may need to weigh in on "When" - such as in the sequencing of dependencies, to mitigate technical risks).
    • At the heart of the matter, architecture is about value-creation and value-protection for the business. Thus, an architect may rightly justify expending effort in creating and maintaining artifacts for a variety of valid reasons.

    Posted by No comments:
    Labels: ,

    WordCount

    Copyright

    © 2001-2026 International Technology Ventures, Inc., All Rights Reserved.