It is a long video, but Folding Ideas‘s Line Goes Up – The Problem With NFTs is a great video on NFTs and why it is a horrible concept.
Hat tip: I found the video through a tweet by Lindsay Broadwell
Someone posted a link to this story on Facebook
How a $300K Bored Ape Yacht Club NFT accidentally sold for $3K
The Bored Ape Yacht Club is a collection of 10,000 NFTs, each depicting an ape with different traits and visual attributes. It may sound arcane, but it’s one of the most prestigious NFT collections in the world. Jimmy Fallon, Steph Curry and Post Malone are among its star-studded members. Right now the price of entry — that is, the cheapest you can buy a Bored Ape Yacht Club NFT for — is 52 ether, or $210,000.
NFTs is a ridiculous scam, where you pay a fortune to own a computer graphic, which other people can freely copy and have themselves. Many NFTs are connected to existing art work, digital or digitalized, and are often created by people who have no rights to the original artwork, earning money on other peoples’ intellectual property. This is not the case with the Bored Ape Yacht Club images, who were created specifically for usages in NFTs. It is not clear to me, whether the right to the intellectual property is transferred at the same time. It appears from other articles that this might be the case, but often this is not the case, and the NFT is just a proof that you own “the original” digital version of the digital artwork – something which is nonsense, because that is not how digital images works on computers and on networks.
Which is why it’s so painful to see that someone accidentally sold their Bored Ape NFT on Saturday for $3,066.
No, it is not painful. It shows how ridiculous this is.
What really happened was that someone got $3K for something, instead of the $300K that they wanted, because they made a mistake. This is something which is reversable in most transactions, but not with NFTs.
The rest of the article goes into several examples of stupid mistakes in cryptocurrency, which depends on the same technology as NFTs (blockchains), clearly showing a major issue with decentralized assets, where it is not possible to reverse mistakes.
One interesting thing about the Bored Ape Yacht Club, unlike a lot of NFTs, is that because you actually get the rights of the digital artwork, you are actually buying a real product. Not “the original” artwork, but rather the rights surrounding the artwork. This makes them less silly than NFTs of art where the rights to the image doesn’t transfer as well. It also means that it is nothing new – the trade of intellectual rights to an artwork has been around for a long time. So, if someone tries to use this as an good example of NFTs, remember to point out that people don’t just by the NFT when buying an image in this collection, so it can’t be used as an general example.
Most science news in recent days have been focused on the Perseverance Mars Rover and its landing on Mars. However, that is not the only major science news in recent days. We have also had the publication of the news about million years old mammoth DNA being sequenced.
The Guardian reports on this: Million-year-old mammoth genomes set record for ancient DNA
Teeth from mammoths buried in the Siberian permafrost for more than a million years have led to the world’s oldest known DNA being sequenced, according to a study that shines a genetic searchlight on the deep past.
Researchers said the three teeth specimens, one roughly 800,000 years old and two more than a million years old, provided important insights into the giant ice age mammals, including into the ancient heritage of, specifically, the woolly mammoth.
This is really exciting, and will help create a more accurate picture of the lineage of mammoths, as well as expand the possible range for future sequencing. As the Guardian states:
Dalén said new technologies could allow the sequencing of even older DNA from remains found in the permafrost, which dates back 2.6m years.
For a good look behind the science, Patrícia Pečnerová, the Postdoc involved in the research, has written a great write-up: Pushing the limits with million-year-old DNA
The write-up gives an interesting and humorous look behind the scenes, as the starting paragraph clearly shows:
I had low expectations when we went into the lab to extract DNA from samples that based on geological evidence were 600 thousand to 1.2 million years old. At that point of my PhD, I already knew better than to put faith in high-risk/high-gain projects. And attempting to extract DNA older than has ever been done before topped the list of some pretty funky projects that I have been involved in, like trying to retrieve DNA from rocks from the ocean floor. Such efforts rarely yield results and end up in the invisible section of the CV where dreams go to die. My supervisor, Love Dalén, calls it character building.
The article is unfortunately behind a paywall at Nature: Million-year-old DNA sheds light on the genomic history of mammoths
Further reading: Million-year-old DNA provides a glimpse of mammoth evolution (news write-up in Nature)
One of the clear signs that US society doesn’t work probably, is the fact that people have to do fundraisers to cover medical costs and increasingly, to cover basic costs of living. One of the big platforms for these fundraisers, is GoFundMe. Now, the CEO of GoFundMe is speaking out, pointing out that this is wrong
GoFundMe CEO: Hello Congress, Americans need help and we can’t do your job for you
Coronavirus surge of fundraisers on GoFundMe shows why Congress must pass emergency aid for monthly bills, restaurants, small businesses and food.
The opinion piece in USA Today doesn’t tell us anything that most of us didn’t already know, but it is good that a CEO of a company, which is benefiting greatly from the current situation, is speaking out.
The Burger Flipper Who Became a World Expert on the Minimum Wage
As a 16-year-old kid flipping burgers at a Seattle McDonald’s in 1989, Arindrajit Dube was earning the state minimum wage of $3.85 an hour. “I remember feeling privileged that I was going to go on to college, while there were many older workers working at that wage,” he recalls.
He still thinks about the minimum wage, only now it’s from his perch at the University of Massachusetts at Amherst, where he’s possibly the world’s leading authority on its economic effects. Dube’s research is guaranteed to get a bigger audience as Democrats in Congress attempt to make good on President Biden’s pledge to raise the federal wage floor to $15 an hour by 2025.
Intuitively, it makes sense that increasing the minimum wage, would force companies to increase prices, drive down sales, reduce company profit, and will even force companies into closing. Fortunately, as with many things, intuition is wrong in this.
This is for a few reasons:
Yes, there might be companies surviving on the very margins, which can’t increase their sales, which will close, but my guess is that many of those companies already have closed during this pandemic.
Further reading: Home Articles Making the Case for a Higher M… SHARE: Tom Williams/CQ Roll Call Making the Case for a Higher Minimum Wage by Arindrajit Dube
Big Tech as an Unnatural Monopoly
Interesting piece by Tim Brennan in the Milken Institute Review, where he takes a look on Big Tech as monopolies, why they defy the current anti-trust laws, and what can actually be done about Big Tech.
Further reading: Rethinking Antitrust by Lawrence J. White (also in the Milken Institute Review)
This COVID-vaccine designer is tackling vaccine hesitancy — in churches and on Twitter
Immunologist Kizzmekia Corbett helped to design the Moderna vaccine. Now she volunteers her time talking about vaccine science with people of colour.
Kizzmekia Corbett’s twitter feed can be found here.
It is a low bar that President Biden has to clear, but I find it so nice that the US now has a president who is willing to thank people for their hard work
To everyone at the NIH — all the doctors, scientists, and researchers fighting this pandemic and saving lives — thank you from the bottom of my heart. You’re truly the best America has to offer. pic.twitter.com/lLpdZSLdjX
— President Biden (@POTUS) February 12, 2021
After writing the headline, I realized that there are actually two myths around genius programmers – the one I am going to address in this blogpost, and a myth surrounding the importance of genius programmers in teams, which I might have to address some other time (short hint: teams are more important than any individual).
Yesterday, I spent a couple of hours at the Emergent Works 2020 Summer showcase where people who were part of the mentee program at Emergent Works showed what they had learned over the summer. It was really impressive, and shows how a good mentor can help you learn a lot in a short time.
During one of the presentations, one of the mentees mentioned that one of the most important things he had learned, was that you don’t have to be a genius to be a programmer, and mentioned that that had always been his impression before.
Since I have been working in the tech field for a couple of decades, I tend to forget how people think of people in the field, so this comment really made me think about the perception many people have of people in the field. Especially people who don’t really know anyone in the field. And it is true, there is the whole idea that to be a programmer, you have to be a genius.
This impression is perpetuated by the stories we get out of the tech field. About the big successes, generating multi-million fortunes for the founders and early employees. Here people involved, mostly young white men, are usually presented as geniuses, that have done something that no normal person could have done.
The truth is, this is just a myth. A damaging myth.
There are obviously a level of skill involved, but a lot of it has to do with connections and the sheer dumb luck of being at the right place at the right time.
In reality, the tech field is not characterized by these people. Most people who work in the tech fields are not geniuses, but rather ordinary people who have learned a particular skill set. Not necessarily an easy skill set to learn, but one that most people can learn if they have the chance.
It is also important to remember that many people who work in tech don’t program, but fulfill other roles, such as testers/QA, business analysts, program managers etc. Here the skill set needed is different, and again something most people can learn.
In a time where we desperately need more people to go into tech, we need to dismantle this myth of having to be a genius to work in tech. We obviously welcome geniuses, but most people, also those working in tech, are ordinary people. We need to show everyone that tech is a viable path, even if you haven’t grown up with a computer, even if you don’t spend all your spare time on programming.
Note, that I am not arguing that working in tech is necessarily easy. It is a field that is constantly changing, and where you need to put some effort into keeping up. But this is true for many other fields as well, and no one claims that you have to be a genius to work in those. Instead people agree that you have to put in some effort to getting into the field, and in staying in the field.
So, in other words, the myth of having to be a genius to learn to program, or to work in tech, is one that needs to go. We need it to go, because it is a barrier for people who are well qualified to work in the field, but get turned away by the belief that it requires something extra-ordinary of people. This needs to end.
A note on Emergent Works. It is a wonderful organization, which describes itself as:
Emergent Works is a nonprofit software company that trains and employs formerly incarcerated people.
The organization has a special focus on Black and Latinx people, since they are so over-represented in prison and under-represented i n the tech industry.
If you have money to spare, consider helping them with donation. If you are in a leading role in a US tech company, consider hiring them for software development. If you work in tech, and are willing to use some of your spare time, consider becoming a mentor.
I thought I’d share a few links about tech related stuff that I have found interesting in recent times.
Extreme Programming Creator Kent Beck: Tech Has a Compassion Deficit
Before, Beck saw technologists as “us” and management as “them,” he said. Now, he is “them,” and his view has changed.
“I do my one-on-one coaching, but I’m also in the room helping make strategic decisions with very little information, and I’ve gained a lot of respect and empathy for those decision-makers,” he said. “As a punk-ass programmer, I’d grumble about ‘management.’ Well, they have a job to do, and it’s a really difficult job.”
So, the capital-M management is alright with him. But that doesn’t mean Beck’s view of tech leadership is entirely rosy. Many of his anxieties about the tech industry center on power players and their evolving stances on issues like remote compensation, racial justice and content moderation.
“Not a lot makes me hopeful,” he said. “You caught me in isolation [due to COVID-19 precautions]. So this is not my day for bright sunshine.”
Kent Beck was the creator of eXtreme Programming (XP), which is probably the most programmer friendly agile methodology, and which has come up with many of the techniques and tools which is widely used in systems development today. I found this interview interesting because it shows how Kent Beck has evolved and shifted his focus to a much broader perspective than in earlier days.
For doubters of agile, there is also a great question/answer:
You signed the Agile Manifesto almost 20 years ago. How do you feel about agile now?
It’s a devastated wasteland. The life has been sucked out of it. It’s a few religious rituals carried out by people who don’t understand the purpose that those rituals were intended to serve in the first place.
I think he is a bit too pessimistic, but I also understand where he is coming from. From those of us, who have used agile for many years, it is some times scary to realize how little has improved over the years, and how little understanding there is of the ideas behind agile. When I try to explain to people that one of the main strengths of agile is rapid feedback, they all too often fail to understand that this is not just about implementing automatic testing (though that is a given), but also on making measurements and giving outsides the chance of providing feedback – either directly or through their behavior.
Agile and Architecture: Friend, not Foe
Continuing in the realm of agile, here is an article that is really partly a sales pitch for a book. Still worth reading nevertheless.
As an architect, I am frequently asked about the role that architecture can play in environments that practice agile development methods. The core assumption behind this question is usually that agile teams don’t need architecture or at least don’t need architects.
I once took a course by Kevlin Henney called Architecture with Agility, which went into how software architecture and agility could co-exist. One of the major points in the course, is that good architecture is a function over time. Things that were good decisions at one stage, can turn into being bad decisions later, when things change. As a natural consequences of this, you want to defer decisions as long as possible.
Gregor Hohpe seems to be making the same point, but he also makes the excellent point that software architecture allows you to defer certain decisions, until you have the knowledge to make it.
I have ordered his book, and am looking forward to reading it.
Blockchain, the amazing solution for almost nothing
We all have biases, and my bias regarding blockchain is that it is an over-hyped technology which has been born out of a completely useless idea (crypto currency). There are many reasons why I feel this way, but I don’t think I have seen any article describe my feelings about the technology as well as this article by Jesse Frederik.
I’ve been hearing a lot about blockchain in the last few years. I mean, who hasn’t? It’s everywhere.
I’m sure I wasn’t the only one who thought: but what is it then, for God’s sake, this whole blockchain thing? And what’s so terribly revolutionary about it? What problem does it solve?
That’s why I wrote this article. I can tell you upfront, it’s a bizarre journey to nowhere. I’ve never seen so much incomprehensible jargon to describe so little. I’ve never seen so much bloated bombast fall so flat on closer inspection. And I’ve never seen so many people searching so hard for a problem to go with their solution.
I am sure that many blockchain fans can point to examples in the article where it is unfair, but it doesn’t change the overall message. Blockchain is, at its current state, completely over-hyped and largely useless. The article kindly doesn’t mention goes into this, but the performance issues of blockchain technology makes it useless at its current state, and it seems like the only solution to the performance problems is to basically redefine the basic premises of how permissions should work (see e.g. Performance and Scalability of BlockchainNetworks and Smart Contracts (pdf).
Book review of Accelerate: The Science Behind DevOps – Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim.
If you have been at any programming or agile related conference within the last 8 months or so, you will probably have heard people recommend Accelerate. One of the reasons it is often recommended is that it explains the importance of DevOps for high performing tech organizations. This is not really anything new, but what Accelerate does, is base it on actual science, and not just anecdotes and opinions – something we see all too often in the tech field.
The findings of Accelerate is based upon the survey data collected through the yearly survey “State of DevOps” in the years 2014-2017. Those data clearly demonstrated that a high performing organization performed much better than a low performing organization, but they could also be used to explain what caused this differences in performance.
The book is split into 3 parts, a conclusion, and some appendixes. The first part explains the findings, the second part, the science used, and the third part is a case study contributed by Steve Bell and Karen Whitley Bell. I will go through each part separately below.
The first part of the book is called “What we found”, and what they found is certainly noteworthy. They looked at some key indicators of software delivery performance, and found that a high performance organization had the following performance compared to low performance organizations:
These numbers are from page 10 of the book, and show a much greater difference than most would expect, no matter how big a proponent of DevOps.
The rest of the first part of the book goes through their other findings, which identifies “24 key capabilities that drive improvement in software delivery performance, and, in turn, organizational performance”. According to the authors, “[t]hese capabilities are easy to define, measure, and improve”.
I won’t include the list here, but many of them relate to DevOps practices and lean management practices, though there are a couple related other things, such as architecture. One thing I will mention, is that the findings indicate that while culture has an influence on the use of DevOps techniques, the use of DevOps techniques also have an influence on culture, which changes as a result of that.
None of the mentioned capabilities are new, but here we have, for the first time, evidence that they actually work, and help improve performance.
The second part of the book, “The Research”, goes into how the research was conducted, and why survey data was suitable for the research. It doesn’t include the actual data, which would have been nice, but I can understand why that isn’t the case (breach of confidentiality etc).
I can’t recall seeing a similar chapter in any other book on programming/systems development, and I highly applaud it. I also think it was a smart move to put it in the second part, rather than the first part, as most people will be more interested in the findings, rather than the methods behind finding them.
The third part of the book, the case study contributed by Steve Bell and Karen Whitley Bell, is called “Transformation”. They takes us to Ing Netherlands, a world-wide bank, where they have been involved in a cultural change, started and lead by the IT manager, enabling the organization to become high-performance.
To be honest, I find this part to be the weakest part of the book, both in content and in presentation, but it does provide a nice overview of practices on the team, management, and leadership level (it can be found online here).
All in all, the findings of the book should not be shocking to people who has worked with agile, DevOps etc., but it is nice to have a list of proven capabilities to focus on. It is also a useful tool when debating with management about these subjects.
I highly recommend the book to people working in any aspect of software engineering – be it as a programmer, a project manager, in a leadership position, or in any other capacity.
Sad news from the world of programming, Joe Armstrong, one of the authors of the Erlang language has died
It is with great sadness that I share news of Joe Armstrong’s passing away earlier today. Whilst he may no longer be with us, his work has laid the foundation which will be used by generations to come. RIP @joeerl, thank you for inspiring us all.
— Francesco Cesarini (@FrancescoC) April 20, 2019
I never worked much with Erlang, and have never met Joe Armstrong, but from everything I hear, he was a genuinely nice man.
If you want to know more about Erlang, and how it was used, you can watch Erlang the Movie.
To be honest, I highly doubt anyone outside the world of programming will get much out of that clip, but it is interesting to watch, since it shows what type of problems Erlang was developed to solve. It gives a view into the early days of digitizing telephony, which wasn’t that long ago, considered how long telephones and other forms of telecommunication has been around.