DaedTech

Stories about Software

Sep
17

By

The Decline of the Enterprise Architect

Category: You Asked For It Tags: , | 5 Comments

Happy reader question Monday, everybody!  Unlike last week (exigent circumstances) and the week before (US holiday), I can actually bring you one on Monday.  I’m trying hard not to pull a muscle patting myself on the back.

Anyway, today’s reader question has to do with the enterprise architect position.  Specifically, what do I think of it?

It’d be great to hear your thoughts on [the enterprise architect], I’m sure there’s more than an article’s worth on that subject.

Simple enough.  So let’s talk enterprise architect.

Prior Art on Enterprise Architects and Regular Architects

I have, in fact, talked about the architect position before.  It’s hard not to when you’ve blogged for as long as I have and as much as I have.  The architect role is almost as ubiquitous as the software developer role.

I once talked about the architect role as a pension plan for developers.  The pyramid shaped corporation creates a stigma that staying “just” a programmer means failure in a career development context.  So even as organizations (mercifully) move away from the “software as construction” metaphor, the concept of architect persists.  It persists because it gives companies an organizationally meaningless way to let someone be “more” than “just a developer.”

I’ve also made posts about the needless division between reasoning about software at a holistic versus granular level and about moving beyond this distinction and the construction metaphor.  These probably weren’t quite as provocative, and they didn’t dive into the toxic role of the pyramid shaped corporation in knowledge work.

But it appears I’ve never specifically talked about the enterprise architect.  Well, let’s do that now.

The Impressive Enterprise Architect

What is an enterprise architect, anyway?  Well, presumably, it’s someone who trades in enterprise architecture, which is like architecture, but more enterprise-y.  Let’s ask wikiepdia.

Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”

Wow.  Pasting that into the WYSIWYG made my Flesch Ease of Reading score plummet by 20% as I’m typing this.  That alone probably makes it enterprise-y.  Plus, it plugs in “utilize” as a synonym for “use,” so you know it’s official.

If we unpack — eck, who am I kidding?  There’s no unpacking that rhetorical peacock.  Enterprise architecture is, truly, using a comprehensive approach to practice conducting analysis, design, planning, and implementation to develop and execute architectural patterns and practices that guide organizations through changes related to business, information, process, and technology utilizing various aspects of the enterprise to identify, motivate, and achieve said changes.”

Crap, there goes another 15% off of my readability.  Now only people with tattoos of Gantt charts can read this post.

So what is enterprise architecture, and what, then, does the enterprise architect do?  Well, whatever else they do, they apparently seek to make sure no one ever asks them what they do again.

Read More

Sep
14

By

Addressing Malware Detection from the Outside In

Category: Language Agnostic Tags: |

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look around at the different types of production monitoring that they offer.

I worked as a software engineer for almost the entire decade of the 2000s.  While I was earning a living this way, computers were making their way from CS student dorm rooms to Grandma’s den.  Like so many other programmers of the time, I thus acquired the role of unofficial tech support for computer illiterate friends and family.  I do not miss those days in which malware detection became an involuntary hobby.

Back in 2005, everyone had computers with Windows XP or Windows 98.  And every computer with Windows XP or Windows 98 seemed to attract malware like flies to flypaper.  So I found myself sitting in front of CRT monitors next to dusty towers, figuring out why nothing worked.

I still kind of remember the playbook.  For instance, Lavasoft had a product called Ad Aware.  I also seem to recall something called MalwareBytes.  I favored these because I could download them for free.  At least, I could download them for free assuming the victim’s computer was even capable.  With those tools in place, and with a heaping helping of googling from my own laptop, I would painstakingly scan, sweep, remove, tweak, and repeat.  Eventually, I won. Usually.

It seems strange to think about now.  Ten or twelve years ago, consumers compared brands of antivirus software the way we compare music apps on our phones.  Malware detection dominated our computing consciousness, even for casual users.  But today?  I can’t remember the last time I ran an antivirus scan on my laptops.  I suspect you can’t either.  So what happened to all of this malware?  Did it simply disappear?

The Silencing of Malware

Well, no.  Malware didn’t disappear.  The criminals and spammers of the world didn’t just one day decide to do something better with their lives.  In fact, you might argue that they became more effective.

Most of the pieces of malware from my younger days had lots of bark and little bite.  They’d install themselves on your computer and hijack your browser with obnoxious graphics or spew error messages until your machine crashed.  Some came from would-be vandals, while others tried unsuccessfully to do things sneakily.

But causing some computer neophyte to say “this doesn’t seem right” and call up a young me to fix things — well, it hardly constitutes successful sneaking.  It always seemed, in those days, that malware authors sought mainly to annoy.  And malware detection and removal sought to fix the inconvenience.

In more recent years, however, the consumer annoyance factor has mostly disappeared.  Why?  Because there’s no profit in it.  Today’s malware instead aims to help its authors and users make money.  It does this by quietly gathering data, sending out spam, gaming search engines, and stealing information.  And it does all of this under the radar.

Read More

Sep
13

By

Why NDepend Uses Google’s Page Rank

Category: .NET Tags: , |

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at type rank and all of the other metrics that NDepend will show you about your code.

I remember my early days of blogging as sort of a comedy of errors.  Oh, don’t get me wrong.  I don’t think those early posts were terrible, since I’d always written a lot.  Rather, I knew very little about everything besides the writing.  For example, I initially thought link spammers were just somewhat daft blog commenters.  I stumbled through various mistakes and learned the art of blogging in fits and starts.  This included my discovery of something called page rank.

Page rank had a relatively involved calculation, but that didn’t interest me at the time.  Instead, I found myself dazzled by some gamification.  Sites like this one would take your domain and a captcha as input and spit out a score from 0 to 10 as output.  That simply, they turned my blogging world upside down.  I now had a score to chase and a means of comparing myself against others.  And I vaguely understood that getting more inbound links would increase my page rank score.

Of course, as an introvert, I struggle with outgoing self-promotion.  Cold outreach to people to see if they’d link to me never seriously occurred to me.  Instead, I reasoned that I would play the long game.  Write enough posts, and the shares start to come.  And then when the shares come, so too will the links.  So I watched my page rank inch slowly upward over time.

The Decline of Page Rank

My page rank ticked upward until one day it didn’t anymore.  Turns out, Google slowly killed it over the course of a number of years.  Ten months passed between its penultimate update and its final one.  So there I stood (metaphorically), waiting for a boost to my rank that would never come.

But why did Google kill page rank?  Wouldn’t such an easily digestible construct continue to help people?  Well, sort of.  Unfortunately, it disproportionately helped the wrong sort of people.

The Google founders developed the concept during their time at Stanford.  Conceptually, the page rank algorithm regards a link from site A to site B as a “vote” for site B, by site A.  But not all pages get to “vote” equally.  The higher a rank the page has, the more worthwhile its vote, creating a conceptual feedback loop.

On the surface, this sounds great, and, in many ways, it was.  As you can imagine, a site with a ton of inbound links, like a government study or a news outlet, would accumulate a great deal of rank.  Since employees would carefully curate such sites, you could put a lot of stock in a site to which they linked (and search engines did).  So in theory, you have a democratized system in which the sites best regarded by the public had the best rank.

But in this theory, no link spammers existed.  If you wanted good page rank, you could produce high quality, popular content.  Or you could pay some shady outfit to carpet bomb blog comment sections with links to your site.  Because of this fatal flaw, page rank eventually dwindled to obscurity.

A Useful Reappropriation of Page Rank

For clarity, understand that Google (probably) still uses some incarnation of this scheme.  But they no longer update the easily consumed public version of it.  They now use it as only one of many factors in what they display in response to searches.  The heyday of comparing page rank scores for sites has come and gone.  But that doesn’t mean we can’t use it elsewhere, and to great efficacy.

For instance, consider applying this to codebases.  Instead of a situation where website A links to website B, imagine a situation where type A refers directly to type B.  Now, imagine your codebase as a (hopefully acyclic) directed graph with edges and nodes.  You start to have an interesting vehicle for reasoning about your codebase.

What would a high rank mean in this context?  Well, relatively high rank for a type would mean that other types tended to refer to it at a high rate.  Types with relatively low (or zero) rank would take no dependencies, existing at the edge of your code.  And the types with the highest rank?  These would be types used by other types with high rank.

Read More

Sep
12

By

Side Hustle Ideas: 5 Simple Ones for Software Developers

Category: The Life of a Programmer | 6 Comments

I was originally going to write the next corporate realpolitik explained post, this time about the software architect.  And, while I can and will still do that (tweet at me or something if you’d like to speed it along), I’m just not feeling cynical these days.

I have a nice winter of drifting through the US south planned, running a lifestyle business and generally enjoying myself.  So why not write about something instructional and uplifting?

Like side hustle ideas.

What’s a Side Hustle?

It’s not so complicated.

If your full time work is your full time hustle, then your side hustle is work you do on the side.  You could think of it as a hobby that makes you some money.

For some, that’s all it is and all it stays.  Others might look to it as an eventual job replacement.

If you work 40 or more hours per week, this might seem daunting.  And, it can be.

Instead of spending your recuperation time reading, watching TV, or appreciating your family, you’re carving off a slice to do even more work stuff.  For that reason, you should be sure to find something you like doing.

And also for that reason, I’m going to emphasize more manageable and iteratively achievable side hustle ideas.

This post is mainly aimed at salaried software developers that have never made money outside of a salaried context.  Anyone is, of course, welcome to read along — it’s not like side hustle ideas are exclusive in any way.

But understand who I’m talking to with this advice.

I’m talking to folks with full time jobs that don’t want to risk running afoul of employers (say, by moonlighting) and don’t want to spend all of their waking hours on the side hustle.

Before the Side Hustle Ideas, a Suggestion: Don’t Build Software as a Side Hustle

First up, let me recommend a few hustles not to pursue, particularly for those of you that are first timers at this.  It’s not that there’s anything wrong with these things.  They’re just not where you want to start.

First of all, don’t make a mobile app or build a SaaS.

Yes, you heard me correctly.  You’re a software developer and I’m steering you away from software development.

Why?

Here’s the thing.  You spend all day, every day writing software for a living already.  You know software — you live it and you breathe it.

So if you go home and start a side hustle building software, all you’re going to do is build software.  You’re going to build it, then build it some more, and finally, after that, when it’s finally time to ship, you won’t ship so that you can spend another year building it.

I’m exaggerating, but not a ton.  Bias toward familiarity makes for great procrastination.

Why do you think software developers contemplating a blog spend weeks agonizing about what platform to use or whether to hand code it.  Because you know software and you don’t know writing.  So you dither over unimportant software decisions.

Side hustles are about earning some extra money, sure.

But they’re also about teaching yourself business, which I heartily endorse since continuing to improve as a generalist programmer starts to yield diminishing returns after a while.  So lay down the IDE and dive fully into the business world.

Read More

Sep
12

By

Pair Programming Benefits: The Business Rationale

Category: The Life of a Programmer Tags: , , | 13 Comments

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their Retrace product that consolidates all of your production monitoring needs into one tool.

During the course of my work as a consultant, I wind up working with many companies adopting agile practices, most commonly following Scrum.  Some of these practices they embrace easily, such as continuous integration.  Others cause some consternation.  But perhaps no practice furrows more brows in management than pair programming.  Whatever pair programming benefits they can imagine, they always harbor a predictable objection.

Why would I pay two people to do one job?

Of course, they may not state it quite this bluntly (though many do).  They may talk more generally in terms of waste and inefficiency.  Or perhaps they offer tepid objections related to logistical concerns.  Doesn’t each requirement need one and only one owner?  But in almost all cases, it amounts to the same essential source of discomfort.

I believe this has its roots in early management theories, such as scientific management.  These gave rise to the notion of workplaces as complex systems, wherein managers deployed workers as resources intended to perform tasks repetitively and efficiently.  Classic management theory wants individual workers at full utilization.  Give them a task, have them specialize in it, and let them realize efficiency through that specialty.

Knowledge Work as a Wrinkle

Historically, this made sense.  And it made particular sense for manufacturing operations with global focus.  These organizations took advantage of hyper-specialty to realize economies of scale, which they parlayed into a competitive advantage.

But fast forward to 2017 and think of workers writing software instead of assembling cars.  Software developers do something called knowledge work, which has a much different efficiency profile than manual labor.  While you wouldn’t reasonably pay two people to pair up operating one shovel to dig a ditch, you might pay them to pair up and solve a mental puzzle.

So while the atavistic aversion to pairing makes sense given our history, we should move past that in modern software development.

To convince reticent managers to at least hear me out, I ask them to engage in a thought exercise.  Do they hire software developers based on how many words per minute they can type?  What about how many lines of code per hour they can crank out?  Neither of these things?

These questions have obvious answers.  After I hear those answers, I ask them to concede that software development involves more thinking than typing.  Once they concede that point, the entrenched idea of attacking a problem with two people as wasteful becomes a little less entrenched.  And that’s a start.

Read More

« Older Posts
Newer Posts »