Evolution of Homo Nerdis

2018-08-29 14:48:00
Niclas Hedhman
Original
206

Evolution of Homo Nerdis: From Turing to Trash, is the speech that Niclas Hedhman delivered at the China Open Source Conference 2017 at which our founder has given a speech on open source at the conference. Nature Easy Soft took part in this conference, and listened to this speech. We found what he mentioned in his speech, especially the "small, smart, and smoldering" solution,  resonates with us.

With the consent of Mr. Niclas Hedhman, we put the notes of this speech on our website and shared it with you. Thanks again to Mr. Niclas Hedhman!






I like to have controversial titles to my talks, and this one is no diferent; Evolution of Homo Nerdis,

From Turing to Trash.



Who doesn’t know Alan Turing? That is a rhetorical question. But do you know Mr Trash?
Well, look around you. Most of us in this room, is a representation of that Mr Trash. So, this


is a follow-up of last year’s presentation “Elephant in the Room”, the decline in Software
Developer Quality.


That time I spoke of the What and Why we have Crisis in the Software Industry. This time I will
spend time on HOW we got here, what Threats we are facing and perhaps what the future will
hold.


In the “Elephant in The Room” presentation I spoke a lot about too many people in the
software industry and that we are all too stupid. I think that it is all about Degeneration, that
our successes right now leads to a worse future, and that this has been ongoing for a long
time.


So how does this work? In the beginning, some individuals were able to construct and operate
machines to do “thinking”. They could either connect cables in diferent configurations, or
enter numerical values on punch cards to get these machines to do mathematical calculations,
much better than humans. This was Hard!


This was so hard that a new species was classified, Homo Nerdis Codetus (Coder for short).
Heroes like Alan Turing, Grace Hopper and Edsger Dijkstra basically did the impossible.


Rather quickly, they thought that there must be a better way. Programming Languages were
born. Algol, Cobol, Fortran and even Lisp came very early on. C, Pascal, Forth, Simula and
Prolog soon followed, and hundreds other that are no longer with us.

With Source Code, in something that almost looked like English, the writing software species
filled the new environment with its adaption. And didn’t need to be as smart as the previous
generation. It was easier, but “THIS IS STILL HARD”.


With the advent of programming languages, the breed of Homo Nerdis Programmeris
(Programmer for short) were able to use these texts, that looked like language to make the
machines do things. IT WAS HARD.


But some Programmers noticed that a lot of the things that they had to write, recurred over
and over again. What-if it could be placed into a big Library and Reused when needed.
Eventually, all possible combinations would exist in that library, ready to be used.


With more and more libraries emerging from the Programmers, there was an explosion of
growth in the number of individuals of this breed. But since it was easier, you didn’t need to
be that smart. And because of lacking the smarts, THIS IS STILL HARD!


Home Nerdis Developiens (Developers for short) were in great demand. With these libraries as
a foundation, they created new and ever more complex applications for Humans. The
libraries didn’t fit together and a lot of time was spent getting libraries to work, to convert
types, and replace bad implementations. THIS WAS HARD.


Some developers realized that we can create a mechanism that describe how components
must look like, so that they can be used together, and the age of Frameworks came about.


As the number of Components grew, the more streamlined the components became, the
easier it was to do the work. So the population grew, and it grew so much since high
intelligence was not really required. And THIS IS STILL HARD.


Frameworks and Components bloated the applications enormously. Endless amount of similar
functionality in many varieties. This was not fun. There must be a better way, if we could only
avoid type systems, compilers and schemas in general. Because all that... THAT WAS HARD!


Maybe we can have a way to simply describe what we want in a simpler language, more
similar to English maybe. Maybe it doesn’t really care about types that much, and should we
not write that inside the web pages that we almost only work with anyway? That would be so
much easier, and faster, would it not? Well, at least initially, it will seem that it we can work
faster.


It was easier to get started, quicker to have one’s first webpage do something like displaying
time. “Wow. I am a programmer?” The number of Homo Nerdis Scriptum Kidus (Script Kiddie
for short) went through the roof.

And you didn’t really have to be that smart to get work done. Well, maybe you did, because
THIS IS STILL HARD!


As the Homo Nerdis Scriptum Kidus produced endless amount of more or less useful
applications that only work on their laptops. How to make these applications actually work,
and work for many, many users, 24/7. THAT WAS HARD!


A new breed, the Homo Nerdis Devopolus (Devops for short), emerged with Automation and
Containers. This new species got all the attention, they saved the sinking application projects
by allowing for rapid changes to production systems. Fixing bugs in production systems,
rather than eliminating bugs before getting into production, became a way of life.


More and more ready-to-run applications emerge on the market. Install, Configure and Start.
Devops thought that they created these applications, some scripting here, lambda expression
over there. Voila!


How hard can it be? The Devops ruled the world, growing quickly in numbers and
importance, but unfortunately not in intelligence. And having microservices architecture,
100s of small applications, impossible to understand what was happening on the network,
guess what... THIS IS STILL HARD!


So what is the common theme here?


This is HAAAAAARD!
No matter how much easier things get, it is still hard. 为什么?(Why?)


We don’t like things to be hard. Would Alan Turing and Grace Hopper think that our current
technology is hard? I don’t think so. They were among the brightest minds of their day. You
and I, we are perhaps slightly above the average person. Typically only with a diferent
education and upbringing.


Companies thinks that everything is solved with MORE PEOPLE. I argue that this is

counterproductive, as mentioned in “Elephant in the Room”. Google doesn’t need 20 thousand
engineers. A bank doesn’t need 10,000 people in their IT organization.


We, as an industry, have been in a vicious downward spiral for a long time. Because
something is hard, we create something new, which allows more people to feel that
something else is still hard. Let that sink in for a moment.


We make things easier, which leads to more stupid solutions. And we don’t realize it.


I had a long explanation of what the evidence for all this is, but since I don’t have too much
time, I needed to cut that out. Sufce to say, what we consider normal today, is not normal
when looking back.


SO, is the battle lost? Should we all just pack up and start a restaurant? Well, for legacy
systems, stuck with a lot of people keeping it alive, yes... It is lost. Those systems will soak
up anyone willing to work in that dreadful environment, pretending that it is normal. But
market pressure will eventually collapse that mindset, will be forced out of business, just like
horse carriages were replaced by trucks.


But when starting new projects, when building new products, I think we are at a time when
the Smart people need to step up and get things on track again. The usual way of doing
business is too expensive and much higher risk of failing. Instead we need to DO MORE WITH
LESS. Small, Smart and Smoldering.


What on Earth do I mean by Small, Smart and Smoldering? You heard it here first, as always.


Small, Smart and Smoldering... I am talking about downsizing teams and entire departments,
that leads to Smaller budgets and Smaller scope. The technology stacks need to be simplified
and made smaller, and the large footprint systems with 100s of computers for most
applications are to be reduced down to half a dozen machines.


Smarter People understands how to get better performance out of the fewer machines. Don’t
spend the entire budget on serialization and deserialization over the network. Smart ways to
on-boarding people to new projects, using Smarter Processes and Smarter Organization,
ultimately providing better feedback from all aspects of Software Development.


Smoldering is the combustion without flame and without smoke, like charcoal grilling your
steak. I am convinced that we are on the cusp of a revolution in software development, where
high energy teams will depart from convention, from bloated frameworks and demoralizing
processes. I am certain the age of DevOps and Script Kiddies are soon over, at least for the
new trail blazers in our industry. The only question is; How will this look like?


Fewer People is going to be the strength in software development in the future. We will see
Smaller groups make Greater Things. The Future is Bright!
Bright Ideas
Bright Projects
Bright People
Thank You.



Write a Comment
Comment will be posted once reviewed.
blog-why

Why choose ZenTao

Leading

Serving 30,000+ teams

Serving 200,000+ projects

Serving 800,000+ developers

The #1 in local market share

Free & Open

Open source and unlimited to commercial

Powerful extension mechanism and various plug-ins

Available on Github

Either Self-Host or Cloud Apps

Professional

Refined ALM support

Zero downtime upgrades 

Integrate Git and SVN (pro)

Word and Excel import & export (pro)

Preview-Edit-Diff document online(ent)

Integrate OPS-Attendance-Feedback(ent)

Guaranteed

ZenTao team has involved in open source since 2004

Frequent releases and free upgrade forever(even self-hosted) 

Instant and powerful support for 20000+ companies

Easy

Out of the box, Less config

Nice price for small team($9.9)

Design to adhere Scrum Best practice

For Agile but not restrict to Agile

Flexible

Applicable for different sized teams

Applicable for Agile/Waterfall

Modules can be used in any combination

Convenient customization