Category: Professional

It’s not fashion itself that’s irritating, it’s the rabid advance of the crowd so devoted to the fashion. I mean fashion in the broad sense of a popular, conventional approach to anything. I’m not writing only of clothing or hairstyle. In fact, those aspects of societal obsession have diminished compared to my youth when wearing a mohawk to school might have been a blatant invitation to fight. (Not really in Martinez. Not enough kids to divide into serious cliques.)

In proper perspective, fashion can be fun. You know the choice is arbitrary and you can cast it aside for something more important. You’re going to wear sandals to the beach, not your Doc Martens. That’s logical. Pick the higher values over the lesser values. In a tie, flip a coin.

I’ve always enjoyed working out the best solution versus whatever’s popular. I don’t mean picking the opposite for the sake of being provocative. I mean deciding for myself what’s right and not being afraid of the ninnies and the twits. I loved computers at first sight. My first experience was pair-programming BASIC on an Apple II+ my math teacher hauled into school every day. Despite being mysterious, the computer behaved deterministically. Perhaps there were multiple ways to achieve a result, but it was the result that mattered.

It did not occur to me to consider whether messing around with personal computers was fashionable. It was a niche hobby like playing Dungeons and Dragons, but the music I listened to said it didn’t matter. Alice Cooper commanded “Flush the Fashion”. The clones destroyed government. They were destroying time. Mike Ness complained “you look so plastic, you could be a barbie doll” and that he was “anti-fashion”.

When I discovered PHP in 1997, it was obvious to me how much better it would make building web applications. I was immediately more productive. To that point in Internet history, a hard line divided content (HTML files) and data processing (Perl cgi-bin files). PHP allowed merging and intermingling the logic and the presentation.

Despite it being obvious to me, building with PHP was a hard sell to clients for a few years. PHP was not fashionable. It didn’t come out of giant software companies like Sun or Microsoft. Eventually, though, that we could build better sites at lower cost won out. PHP might never have been fashionable. It moved quickly into being the default choice that fashionistas declared uncool, boring, too easy. Yet, it remains overwhelmingly dominate. (PHP is probably used by about 75% of all Web sites).

I recently stumbled on Larry Ellison’s comment about fashion from 2008. Dan Farber’s piece about it from then covers the details. (Oh for the days listening to The Gillmor Gang commuting to Berkeley!) Ellison described the computer industry as more fashion-focused than women’s clothing.

The interesting thing about cloud computing is that we’ve redefined cloud computing to include everything that we already do. I can’t think of anything that isn’t cloud computing with all of these announcements. The computer industry is the only industry that is more fashion-driven than women’s fashion. Maybe I’m an idiot, but I have no idea what anyone is talking about. What is it? It’s complete gibberish. It’s insane. When is this idiocy going to stop?

We’ll make cloud computing announcements. I’m not going to fight this thing. But I don’t understand what we would do differently in the light of cloud.

Larry Ellison speaking at Oracle OpenWorld 2008

Fifteen years later, it might be hard to remember when putting all of your data in the data center of a online retailer wasn’t a default choice. It became fashionable, and Oracle hopped on the bandwagon despite its leader considering the conversation to be idiotic. Of course, today many people are rethinking the choice in the context of intrusions. Microsoft, infamous for building systems vulnerable to security breaches, lost control of their entire cloud infrastructure in 2023. A researcher at Tenable found a way to access cross-tenant applications and sensitive data, such as authentication secrets. Everything in Azure was exposed, including access to banks.

You won’t hear someone argue for cloud computing by calling it fashionable, but you will hear this argument in essence, wrapped in palatable terminology. You’ll hear that all the big players are using it. The point is both true and a non sequitur. More insidiously, anything fashionable will be described as modern.

Modern is a euphemism for fashionable.

Forget it. Being modern (fashionable, hip, chic, stylish, bussin’, whatever), does not belong in software architecture. Ellison said he wouldn’t fight it (cloud computing), meaning he’d cynically adopt the buzzwords. That went beyond not fighting. It was surrender.

Instead, I recommend you decline the fight. Do what you know is best. Make choices based on rational arguments. I’m not referring to cloud computing specifically. Renting virtual server capacity often solves a problem perfectly. Reflexively choosing any solution based on how often you read about it on social media can only ever be right by accident.

Flush the fashion.

Writing up the design of a software system boosts productivity because it’s much less effort to fix bugs in the design before you write a line of code.

Since John ranted about ranting this week, I almost let out a get-off-my-lawn rant about how the kids these days don’t know about working out a design in writing before coding. Then I remembered that I only know a little bit of everything there is to know, but I am convinced it’s best not to give any energy to anything I don’t want more of.

Of the many subjects I studied years ago when earning my degree in computer science, software engineering persists as the most useful. I can barely recall how to code in Ada or Pascal, but I often return to the principles of discovering requirements, putting software design down on paper and planning for the entire system life cycle. I still keep those textbooks on a shelf in my office. I have a fond feeling about them similar to the one I get from the first edition Dungeon Masters Guide. Something nudges me to crack open those old books because there’s bound to be some wisdom I missed before.

I was thinking about Software Engineering Concepts by Richard Fairley as I read a blog post titled “Waterfall” doesn’t mean what you think it means. That post focuses on the misconceptions of waterfall versus agile. Perhaps the amorphous thing that people call agile enables the neglect of proper documentation. Although, I’ve observed this behavior long before anyone had a fashionable label for their lack of process.

Although I learned of the power of working up a design in writing while in class, the practice proved itself over the years. The argument is simple — it’s much less work to fix a flaw in the design when it’s just words and diagrams. Coding is comparatively more expensive, especially if you must throw away hours of work to start over. This might not be obvious to everyone.

Here’s my understanding of the software engineering process.

• Discover the purpose of the system by writing down stories about how users will interact with it. Write them as non-technical stories that the client can understand.
• Describe the data model, again in plain language. Validate the data model versus the user stories. Possibly add more stories and expand the data model. A data flow diagram can help. Describing operations between the data objects can help.
• Write down any constraints you can think of. Some are obvious, such as when you know you’ll code the system in PHP because it’s the language you’ve been coding in for more than 25 years. Some constraints are standard, such as response times or maximum simultaneous users. Constraints can cause you to discover new user stories or to adjust the data model.
• Describe the most important algorithms, database structures and objects. It isn’t code yet, but you’re thinking about how it would be coded and teasing out problems that might come up as the parts interact. It may cause you to return to any earlier step and revise your thinking, but that’s easy because it’s just words.
• Figure out how you will test the system once it’s complete, otherwise known as a test plan. Figure out how the system will be maintained over time, otherwise known as a maintenance plan.
• Start writing code, including unit tests. Keep validating that the code you’re writing honors the design. Write code that can be tested with the test plan. Write code that can be maintained. Revise the plans if necessary.
• Run the test plan. Hopefully, unit tests were all passing and nothing major pops up that will cause a change in the design.
• Deploy the system and stick to the maintenance plan. If you discover a flaw in any of the previous work, update what you wrote before.

Quite often, I see the above process compressed into a Statement of Work written up by a non-technical client, a list of tasks brainstormed in an hour for the purpose of estimation, and then a lot of churn on closing tasks. It’s easy, like wolfing down a bag of chips. Of course, it can give you indigestion or worse if you go back for seconds or thirds or …