The bug of security theater

It seems like the Internet and web-based services have been around forever and work well – from anywhere, just open up a browser on any device that supports Internet browsers. Well, at the end of 2016, there is a new bug going around, preventing many different services from serving. The bug of security theater.

After many a security breach, billions of records exposed or stolen, millions of people affected in some serious or minuscule or unknown ways, the providers have learned that security matters. However, security breaches are still relatively rare, unsystematic, and often caused by an ‘oops’ – some singular event that wasn’t supposed to happen, like operator error.  In many cases, there is simply not enough information how to prevent the break-ins and unwanted exposure or loss of data. In other cases, providers may be able to do somewhat better – but at the great expense of re-training staff, updating and enforcing stricter policies, and re-working technical systems.  

Still, there is something that is relatively cheap and easy to do, and improves security – at least in the eyes of users and media.  Security theater is commonly show-cased in the user interface. Many-factor authentication, secure codes sent by email or text message or by audio in a phone call, highly sophisticated personal and public questions going back many years for the users to answer – all for the privilege of accessing the same old web-based email account.

Many providers are requesting a smart phone# to authenticate against, which is good for them – more data, but bad for us – more advertising phone calls.  Many providers require a live exchange of data over the phone or email before allowing access, which is hardly good for them, and definitely bad for us – the wait times are often unreasonable.  Still others insist on following up online communication with a phone call – which is bad for everybody, because if we wanted to communicate by phone, we would not bother with online access at all.

Security is different from security theater.  Security is hard, and should enable us to do more business. Security theater is cheap, generates false sense of being protected (and very real frustrations), and prevents us from doing things we want to do. 

Conversations on diversity

I want to share a few  interesting conversations with or about women in technology industry: 

A young white American male, on attending Grace Hopper Celebration - a conference by and for women in computing

- It felt really weird to be part of the small minority of men there. I usually feel like I belong when I go to technology events, but this was different. 

---

A different young white American male, works in a heavily male-dominated office

- So, as a member of the majority, what can I do to welcome more women to participate in tech?

Another young white American male, same workplace

- But we welcome women! We are a total meritocracy.  Women just do not apply.

---

Mid-career software professional, female, working in the public sector

- Yesterday, I suggested researching a way to automatically add new users to "AR" group. I told it three times. It was ignored and dismissed. By the end of the meeting, Garry said exact same thing. Adolfo carefully recorded it in his plan of action.

Experienced white male, in response to the woman’s comment above

- Sad that it upset you so much. How much easier would be your work if you just shrug and ignore, even better, do not notice these little injustices. The credit, that little bit of authorship honor, was stolen from you. The whole incident was a waste of time and emotions.

---

Another professional woman

- I get a flood of emotion when I realize that consistently in our staff meetings one of my male coworkers echoes my comments or objections loudly for the whole group, either in agreement or augmenting them with his own thoughts in legitimate discussion. This is a first in my career that I feel consistently heard, even with the many female coworkers I've had. And he is raising a daughter.

Brilliant hare?

We called him Tortoise because he taught us. - Lewis Carroll

In a conversation about work, a colleague mentioned that a person who was perceived as absolutely brilliant by everybody who knew him. People believed he was brilliant, because he was always coming up with answers for every complicated technical problem or question very quickly.

Being quick is important for success. ‘Quickly’ is one of the more popular words in LinkedIn recommendations. Speed-reading, speed-listening, and occasionally even fast typing, are considered good and important skills for technology workers.

Yet, quick can be an enemy of good. Quickly pushing out code typically leads to bugs, technical debt, and poor architecture. Quick decisions often turn out to be poor – or maybe not, but only if they happened to be lucky, rather than well thought through. The engineer everyone’s raving about for quickly fixing bugs, is quietly introducing dozens of new ones.

“Thinking, Fast and Slow” by Daniel Kahneman talks about the different ways people are wired to think, one by applying simple rules and pre-existing biases, another for consciously considering all available information. The ‘quick thinking’ leads to stereotyping, emotional, and subconscious choices. The slow option is the opposite – calculating, conscious and effortful.

It may be time to rethink what it takes to be brilliant. Slowly. 

Work hard, aim high, fall, and keep going

I was told that this young woman in a sparkly dress is a top-level athlete at a local ice skating rink.  She came out on the ice with powerful confidence of someone who’s done that a hundred times. Indeed, she was very good - graceful glides, balanced turns, fast spins. Then she jumped. And fell. Got up and kept skating, and then jumped again. And fell again.

Those were complicated, high above the ice, many-turns jumps, and she did manage to land nicely a few of them. Still, she fell four times in a two-minute skating routine, all the way down on the ice. And each time she got up, picked up the beat in the music, and continued skating the program. More than that, she continued to attempt those high complicated jumps over and over again, never mind the falls.

The crowd was watching from the bleachers in awe. Down on the ice, this young woman was living through these, most likely unremarkable, minutes of her life – work hard, aim high, fall, and keep going at it. Throughout the evening, the skater kept attempting more jumps, sometimes landed nicely, but quite often continued to fall. She was the best, and that was exactly how she got to be the best, by pushing through the failure, the pain, the embarrassment, no matter the falls, jump after jump. 

Legacy code cycle

“Remember, code is your house,
and you have to live in it.”
― Michael C. Feathers
"Working Effectively with Legacy Code"

Every project goes through stages. First, there is excitement of design, green-field development, seeing things work. Then there are bug fixes, additional features that may or may not fit the originally designed architecture, little tweaks and changes to accommodate the cases not covered in initial development. And then there is support – making changes based on the usage patterns, keeping up with changing environment, fixing the harder-to-find bugs.

Successful projects go through these stages in a spiral: as time goes on, large sections will get re-written to update architecture, move to a new technology stack, fix the underlying issues of the old code base. And then more bugs will be written, tweaks and updates will be needed and will tarnish the shiny new design, and environment will continue to change.

No matter how many times we’ve been there, for most large successful projects, a large portion of the lifecycle is when the code base is full of slow-moving, bug-prone legacy code that is hard to work on. Eventually, an investment will be made to rewrite or refactor the worst pieces, yet a short while later the development organization finds itself facing the same problems again.  

At the same time, developers are being continuously schooled on writing better code, doing TDD, working with legacy code, but all this knowledge turns out to be very hard to put into daily practice.

Legacy code keeps happening, despite the best intentions.

Are we ready for code review?

We have been talking about the better ways to do code reviews, and there are plenty. There are great tools to make code sign-off by someone other than the code author a required part of the process. It is important to keep code reviews short and casual. Very little code and only a few people should be involved in each event. Reviews should be done often, as much as a couple of times a day, and everybody on the team should participate regularly. There are ways to limit the conversation to the most important topics – logical flow, proper use of language features, good naming, while leaving formatting, test coverage, and many other issues to the automated code checkers.

The most interesting conversation, as it typically happens, took place after the formal presentation. The biggest problem of code reviews, and all other technical reviews, is that we, the developers, tend to take the critique as a personal assault.  People brought up multiple instances when they tried to communicate code feedback to a colleague, and instead their comments were heard as snarky and demeaning. We discussed learning to be nicer, working on improving Emotional Intelligence and social skills, making sure to provide comments on good things as well as bad.

However, this is just one side of the problem. There are at least two parties involved in delivering feedback: a person who endeavors to give the message, and the person who is to get the information. The person who receives feedback must be open and involved into how feedback is provided. In order to learn from and benefit from feedback, we also need better social skills and EQ, as well as trust in the system and the person who is delivering the feedback. 

OO is getting old and tired. But is it dead yet?

Here are a few thoughts inspired by an excellent presentation with a provocative title “Object-Orientation is Dead, too” by Dave Thomas aka @pragdave.

OO has been taken to mean classes, inheritance and polymorphism, as implemented in a variety of programming languages. As we typically build code, the proper class design is to commingle state and behavior. Inheritance provides a simple way to vary some but not all aspects of behavior on connected objects. And polymorphism provides a way to package different behaviors into look-alike syntax.

Together, these features make for an incredibly flexible system, with many different ways to design abstractions, express dependencies, and store state in many objects across the codebase. Other words for flexible are ‘complex’ and ‘complicated’. The notion that having all this flexibility is good and powerful and smart encourages mixing a variety of abstractions and implementations, and long and wide dependency trees. As systems and corresponding codebases grow over time, accumulating ideas and approaches from many people, they grow more fragile, more tightly-wound. Code also becomes more dependent on the past history, rather than the latest, and therefore best, understanding.   

We know all that because OO had had a great run in the last 25+ years. Java, in particular, has been one of the most popular programming languages since it came out in mid-90s, both by the amount of code written and number of people writing in it. .Net platform is heavily OO and is very popular as well. C++, while not exactly a strictly OO programming tool, is frequently used for OO-style development. Lots of complicated projects have been attempted, and plenty completed, using the OO paradigm. Many people joined the ranks of OO developers, people with varying amounts of education, imagination and cleverness.

In the last quarter century OO paradigm has been applied to many complicated development projects, at times by less-than-stellar developers, and often by diverse groups working independently and inconsistently. OOP came out somewhat scathed, bruised by the many broken abstractions, blemished by millions of lines of legacy code, but by and large OO has delivered on its promise to provide a way to make large and complex systems possible.

So, is OO dead yet? Or, rather, are we ready to move on to something newer and better?

It’s been many decades since OO first showed up, handily won over then-popular procedural programming style, and far eclipsed the popularity of the functional approach. We are now older, wiser, and have more experience. Is OO still the silver bullet it has once been? And what are our options?

Functional languages are powerful, deeply loved by their communities, and offer a paradigm that can rival OO tools in solving complex problems. Yet, the functional approach has not enjoyed nearly as wide an adoption among broader development community. It also did not have such a testing 25+ years, as software projects grew larger, more complex, and continuously involved larger numbers of less skilled people than ever before.

The functional paradigm is worth exploring again, with the experience we did not have back when OOP originally came along and took over the software industry. But the winning paradigm for the next quarter century is far from certain.  

Solving for Passion

For the last few years, I have had the pleasure, and the privilege, to participate in graduating students’ project reviews at a major university.  Students in their final semesters of earning a Computer Science or Computer Engineering degree are asked to come up with and implement a project of their own choosing, within the guidelines set forth by the professor for the course. Students typically identify a user or a client for their work – a university department or research lab, consumers, charitable organizations.

A few dozen projects I have reviewed so far have mostly been spectacular. Students put their heart and soul, and considerable skills and passion for the technology, into this assignment.  However, there are interesting differences in the presented work.

Some cohorts of students appear to have lofty, large-scale goals. They are interested in solving big important problems related to hunger, or low productivity, or deadly deceases for large populations using tiniest of tools. The teams pull research from international conferences and large NGOs, make highly speculative assumptions about complicated unknowns, and pull together technologies that are both rare and not really designed for these purposes.

For these projects, results are typically modest, presentations are ambitious on vision and poor on structure, and risk of running into crippling unknowns is high.

Other groups appear to be much better prepared. The projects capitalize on the cutting-edge technologies, tests are neatly recorded on video, and presentation slides showcase the scientific background and beautiful technical documentation.  However, these projects aim a bit lower: gadgets that offer a small improvement on the existing products.  Polish replaces passion.

When the focus is on delivering a good-looking presentation, creativity gets lost, or at least greatly diminished. This batch of working, well-documented projects lacks excitement, grand vision, reach into the unknown.

College is the time to dream, to stretch for the moon, to grow one’s ambitions. Most people go on to have a long and very practical career, where delivering a small improvement is valued higher than big ambitious undertakings. We will all be better off if we had more passion and creativity to go around. 

Beyond the 'happy path'

In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected

- Wikipedia

Software is possible because we have clear, well-defined expectations in a lot of common situations. Given a problem and a particular state of the world, software can reason through known information, and perform according to the expectations.

People who invent software are enterprising, excitable, focused on delivering a working solution for a problem.  Which mostly translates into building software that is great about performing the ‘can do’ portion of the expectations. It is the so-called happy path, where the software works as desired and designed, in the perfect world for the well-behaved user who happens to think in perfect lock-step with the inventor of the software.

However, the world is hardly ever perfect. People and users think differently. Not all users are both well-behaved, and can or will follow the detailed vision of the software designer.

Consider a bank application that allows read access to one’s account balance. It is important that it does NOT

• allow read access to other people’s account balance.
• allow write access to any account balance.
• allow any user behavior to affect other user’s experience and access.

These kinds of expectations are less likely to be included in the specification, because we like to think about software in terms of what it can do, and not what it doesn’t do. These expectations are less likely to be designed into the software architecture, because we like to think of achieving our goals must more, than we like to be concerned about preventing bad things from happening. Finally, these expectations are less likely to be tested, because it is both harder and does not demonstrate a job-well-done even if successful. 

Better handling the non-happy paths requires a more systematic approach to specification building and testing, and range verification.

Leading by good looks

“… you don't get trusted positions just because of your ability. You also have to attract the notice of superior[s…]. You have to be liked. You have to fit in with the system. You have to look like what the officers above you think that [leaders] should look like. You have to think in ways that they are comfortable with.

The result was that you ended up with a command structure that was top-heavy with guys who looked good […] and talked right and did well enough not to embarrass themselves, while the really good ones quietly did all the serious work and bailed out their superiors and got blamed for errors they had advised against until they eventually got out.”

Ender's Shadow, by Orson Scott Card @1999

Likable people that fit within the system do a decent job advancing the system toward success. The kind of success that is easy to imagine, easy to prognosticate, and mostly means being ahead of the competition that does the same thing.

However, if one wants to shoot for the stars, to change the paradigm, to redefine success – expecting good-looking people who think in ways that are approved by the existing system to lead us there is doomed to fail. Occasionally, success is not so much ‘the same thing, just more and better’, but rather a long shot that could turn out to become something different, powerful and amazing. And then there is a need for a different kind of leadership, the leadership that does not work as hard to look presentable, to say the expected thing, to be liked by the superiors.

There have always been unlikeable leaders who changed the world in big and small ways. A few went against the system, and others simply disregarded the system and built their own way. The society at large considered most of them failures during a significant portion, if not the entirety, of their journeys. Others have reached the official definition of success, and occasionally even became liked and popular. Still, leading for change is a risky proposition with high potential for failure.

So when picking a leader, or aspiring to lead, put some thought into what kind of leader you want to follow, or to become. Good looks may not be required. 

Following Plato Dialogues: conversation about estimates

-            So, why do we need estimates?

-          Well, as a customer, I want to have estimates.

-          Great! In what ways are estimates useful to you?

-          Say, I order from Amazon, and if my purchase does not arrive on the estimated day, I get to request a refund.

-          Huh, so you are rooting for the sender to fail, and that’s why you need estimates?

-          I guess so.

-          Any other reason to want estimates or tracking?

-          Well, if as a customer I was promised a certain delivery, and it is getting really close, but the work is less than half done, I can make a determination that I am not getting that delivery.

-          So, the reason you want estimates is to feel reassured that work is being done? To make you more comfortable with the delivery that you do not trust?

What are good and useful reasons to want estimates? 

99 little bugs in the code...

A lot of developers I work with are very good, and many are very productive.  Surprisingly, those are not necessarily the same people. Unfortunately, it is not always easy to tell the difference. 

Once upon a time, the management at the company* where I worked decided that there were too many bugs in our code base, and an effort must be made to deal with those bugs.  So, the team was asked to come in on a Saturday, and work on resolving bugs. The deal included a significant bonus for the developer who closed the most bugs by the end of the day.

Lo and behold, on Monday the winner was announced: the person who got the bonus apparently fixed 27 recorded bugs. He also introduced many new ones, so that the next couple of weeks ended up being devoted to resolving the problems introduced on that bug-fixing Saturday. The team did not dare to record any more bugs, though, for fear of being called in to work on a Saturday again.

The developer who fixed the 27 bugs on that memorable Saturday was getting praised by the management as the most productive employee, while the rest of the team grudgingly worked to resolve the errors he (and, undoubtedly, other people too) has introduced, while the productivity of new feature development came to a stand-still. Since the new bugs were not being recorded, the situation virtually guaranteed that knowledge will be lost as time went on.

---

* The names have been omitted to protect the innocent and the guilty.