Can You Feel the Vibe?

“Vibe coding,” if we have to name it, is the instinct to follow an idea straight into a running system before the bureaucracy wakes up. It’s intoxicating. It’s useful. And left alone, it’s shadow IT with better syntax highlighting.

So: keep the spark, lose the shrapnel.

The Instinct Is Fine. The Invisibility Isn’t.

People aren’t vibe coding because they hate process; they’re doing it because process is slow at the exact moment their brain is fast. You know this dance:

• The idea shows up fully formed (or close enough).

• You need a REPL, a repo, and a data source—now.

• Every extra form to fill is a chance the idea evaporates.

We can wag our fingers about “proper intake” or we can design a place for this energy to land safely. The behavior isn’t going away. Pretending it will just pushes it deeper underground.

Design a Sandbox, Not a Maze

Imagine a paved path that feels like a dirt trail. That’s the job.

I want a sandbox where anyone can mash ideas into code, hit “deploy,” get real feedback… and where we still capture an audit trail, enforce basic guardrails, and promote winners to the grown-up pipeline automatically. Freedom up front, governance in the substrate.

Call it Spark → Prove → Promote:

1. Spark (Fast & Loose, but Logged):

   • Spin up a temp repo/branch from a template (vibe-template), auto-tagged as experimental.

   • Ephemeral env with pre-approved IAM role, read-only test data, and a 24-hour TTL.

   • Everything auto-logs: who did what, when, and which data they touched.

2. Prove (Make It Real Enough):

   • Smoke tests or a tiny checklist: “Does it run? Is there a README? Any secrets in code?”

   • Observability baked in (stdout goes to a sandboxed log store; errors page you, not the on-call team).

   • A lightweight “promote” button that kicks off a review workflow.

3. Promote (Graduate or Archive):

   • If it’s useful, a pipeline migrates code to the main org, assigns owners, and wires alerting.

   • If it’s junk, auto-archive and clean up the infra. No guilt, no clutter.

A win is a win. A miss evaporates without leaving landmines.

Guardrails Without Killing the Vibe

Here are the rails I care about. Most are invisible at run time, very visible at audit time.

• Identity Everywhere: Every scratch environment is tied to an actual person and a ticketable artifact (even if the ticket is created behind the scenes). “Anonymous Lambda” is not a vibe.

• Data Diets: Only synthetic or scrubbed data in Spark. Production data is opt-in, logged, and red-flagged. Boring but mandatory.

• Ephemeral by Default: Time-to-live on resources. If no one renews, it self-destructs (with polite warnings).

• Policy-as-Code, Quietly: Template repos include OPA/Snyk/whatever scans that fail hard on secrets and license issues. People shouldn’t have to think about it; it just works.

• Observability from Line One: Drop a logger, get a dashboard. If your experiment crashes, you get the ping, not PagerDuty at 2 a.m.

• Clear Promotion Path: Don’t make success painful. One click (or simple PR label) should kick off “make this production-ready” automations: code owners, IaC modules, secrets rotation, etc.

Tiny Example: The “Vibe Template” Repo

# vibe-template/.github/workflows/ci.yml
name: vibe-ci
on: [push]
jobs:
  test-n-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest --maxfail=1
      - name: secret-scan
        uses: trufflesecurity/trufflehog-actions-scan@v3
      - name: opa-policy
        run: opa eval --fail-defined -i policy.rego -d src

Nobody asked for a pipeline. It’s just there—fast, opinionated, and loud only when something’s wrong.

Three Questions Before You Push “Run”

If you’re about to vibe code (or bless someone who is), ask:

1. Can this leak anything we’d be fired for leaking? No? Proceed.

2. Will anyone be paged if this melts? Yes? Rethink. Make the blast radius yours.

3. If it works, do we know the next step? Success without a path is just future pain.

If you can’t answer those in 30 seconds, your sandbox isn’t sand enough.

What This Looks Like for Real Orgs (i.e., Us)

• Platform Team: Builds and owns the vibe platform: templates, ephemeral envs, guardrails code. Think “internal Heroku for experiments.”

• Security/AppSec: Codifies “thou shalt not” as policies embedded in the template, reviews the promote stage, not every commit.

• Engineers/Analysts/Whoever Codes: Use it guilt-free. The rule: if you’re outside the sandbox, you’re in grown-up land and the rules apply.

• Leadership: Measures outcomes: # of experiments, # promoted, lead time from idea to prod, incidents caused by experiments (ideally zero). If the metrics go the wrong way, adjust guardrails—not the concept.

Why Bother?

Because the alternative is either (a) slow innovation or (b) silent innovation. Option (b) feels faster until the audit hits, or the clever Lambda starts costing $20k/month in egress fees.

We can have speed and safety. We just have to engineer it. (Shocking, I know.)

---

TL;DR (Because I Know You Skipped)

• Vibe coding is happening. Engrave it in policy or pretend it isn’t—your choice.

• Build a paved sandbox: Spark → Prove → Promote.

• Guardrails = identity, data boundaries, ephemeral infra, policy-as-code, built-in observability, smooth promotion.

• Success path must be easier than stealth path. That’s the only lever that actually works.

Keep the spark. Lose the shrapnel.

Exploring DORA

We are considering implementing DORA metrics to help track and improve our outcomes. I had never heard of the term DORA, but most of the metrics rolled into this moniker I have a history with. As part of the discussion around DORA, we met with a few vendors whose products integrate with GitHub, Jira, etc., to surface metrics. While we didn't end up purchasing a product to help here, it wasn't because we needed to see the value of DORA. On the contrary, we value the outcomes that DORA metrics (et al.) are after; it is more about timing. Through acquisitions, mergers, and growth, we have a diverse group of teams, each at different maturity levels and mechanisms around SDLC. Starting to track DORA-esque metrics when a team may be working to climb up on the maturity curve seems premature for a few reasons. First, we should focus on helping teams up-level their SDLC. For instance, CI/CD is good, so everyone should do that. Second, most mechanisms have some metrics as outputs that we can leverage. If you're doing Scrum, are you tracking the key metrics or meeting every two weeks to plan work? Lastly, we need to be careful when comparing across teams that don't do the same thing or have similar needs. The apples and oranges analogy exists because it works.

As a team leader looking to uplevel the entire engineering organization, DORA and products that capture related metrics sound attractive from a centralized visibility perspective. Being new to the organization, I know relatively little about each team's maturity level, but many feel there is room to improve. Does that mean we are not going to track any DORA metrics? Of course not; we will track the ones with shared mechanisms and leverage that data. Measure, identify, improve, repeat.

P.S. I was pre-Dora The Explorer. But my kids weren't. Geography interests me, so this Dora is fabulous in my book.

Do or do not. There is no try.

I recently dreamed I was in a large audience where an unidentified leader asked for a volunteer to lead a big project. They looked at me, and I said something like I will try, but I couldn't do it alone. Someone else stood up and said they would take on the project, and I could feel the audience staring at me with disdain. So much so that it woke me up.

I am not the type of person who looks for a lot of meaning in my dreams, mostly because I don't remember them. But this one woke me up, and I spent the rest of the early morning lying in bed, considering why it bothered me.

This was similar to talking to others and asking them how we get something done, and their answer is something like, "We don't have the resources." That wasn't the question; the question was, what would it take? My dream was similar because the question was not, "Would you deliver this project by yourself." It's not a question of ensuring a successful outcome; it's a question of pulling together enough for a reasonable discussion on feasibility.

The response I would guide my dream self to give is: Sure, I will lead that big project for you. Then, I would document what it's going to take to get it done and present that to the stakeholders. 

This dream bothered me because I was settling for trying when I knew better.

Secure Apps Take a Village

I reflect on recent experiences and the tension between rolling out features and ensuring the product is secure. Features are flashy. They make good keynotes and/or demos. Features get customers excited and make money.

Security is about the backend. It's not flashy. It's hard to demo security; you probably wouldn't want to even if you could. But when something goes sideways, a security issue will lose you customers. It's like giving your competition bullets—"Hey, did you hear about that security breach at Acme?"

Security is getting more complex and more challenging to do well. Sure, we are smarter and better understand vulnerabilities. However, applications are also becoming more complicated (e.g., log4j and versioning). Complexity makes security harder—it just does. The bad actors are as determined as ever, and their methods continue to evolve.

I attribute much of this tension to the organization's culture. A typical culture pattern is when leadership compresses engineering estimates, and as time runs out, security verification takes place. This leads to pressure to complete verification and remedy errors without impacting the date. Regardless of the number of times that leaders tell people how important security is - actions speak louder. We must ship at this point in the project, leaving uncomfortable conversations and hard choices. 

The tension between shipping and being secure starts early, when most of the time is spent discussing/planning customer-facing features. Sure, security comes up, but in my experience, it gets a different in-depth consideration. If we are lucky,  the challenging security conversations/decisions are before we launch - and not after. Talking about security feels more like a bad thing when it's this late. Further contributing to this tension is when leaders push to make a date, a security issue is identified, and in response, they make statements akin to - "Security is always a priority, so when I push on the date, my expectation is that the system is still secure."

Imagine a product where this culture goes on for a long time; the product is very successful and lucky that lurking security issues are private. With some certainty, this culture will catch up with you, and a critical mass of security issues will arise, requiring engineering resources. Sometimes, the number and/or severity of the problems is so great - that feature delivery is paused, and most of the team is focused on remediation. I bet that for every case like this in the press, many more are not public.

Too often, I have seen teams rely on the hero model: people who, early on, take the risk of spending time on security—which, in my opinion, is under-acknowledged/appreciated. Or the heroes who scramble to fix issues after they are found—typically in a severe time crunch. The hero model is not sustainable and is unreliable for ensuring secure systems. Further, the hero model is often a symptom of something "wrong."

So, let's stop relying on heroes, best intentions, hollow statements, and punishing the bearers of bad news. In a fiercely competitive world, features are prioritized, and security often gets less attention, sometimes even becoming an afterthought. This is a culture war that needs to be waged. 

We must start by considering security not just as a necessity but as a feature as important as any other. We need to talk about it early. We need to do security reviews early and often. For instance, start a threat model on the first day, keep it up to date, and assess design decisions in the context of how it would change the threat model. Activities like this involve staffing security-oriented teams and embedding them into the project teams. Then, empower them to ensure positive security-oriented outcomes. A culture of security is independent of volunteers who take on additional responsibility to ensure a secure system.  We need mechanisms to help people do the "right" thing. Then, acknowledge (early) security wins, such as actions to avoid an event.

A culture of security is hard to change, and as leaders, we need to be honest with ourselves about it — are we backing up our words in ways that will lead to the outcome we want? Look in the mirror. Yes, the words mean something, but it takes more than words.

PS: If you're unfamiliar with the African phrase "it takes a village" - see here.

Classic Tech Books I Still Have My Shelf

Relating some of the books I still have on my bookshelf. They are totally obsolete but found myself reminiscing around what they represented from my past and why they still took up space on my shelf.

One thing to know about me is that by default, I am a book collector. I once had a collection of over 200 technical books on my shelf. That was before the great purge where I donated most of the books and hung onto 30 or so. The great book purge is a story for another time. Suffice it to say that the books that survived were either timeless or ones that I had a fondness for. Here are a few of the fond ones.

The Pink Shirt Book. What would I have done without this book? If you were programming to the "IBM PC" at the time, this was a must have. I pulled it off the shelf and it flopped open the chapter on INT 21. This was the system services interrupt the keyboard, files, etc. I also found a dog-eared page for the INT 27 terminate and stay resident (TSR) details as well. TSRs were the services of the time. This was mostly assembler, then bumping up to C as soon as I could.

The Genie Book. I used this book in conjunction with the Norton Pink Shirt book. It came out after the Norton book, but had more details on writing TSRs, multitasking, and expanded memory. I pulled this book off the shelf and there is a page that was used so much that it was sticking out - having come off the binding. Now that is one well used page. When grabbing the image for this post, I found that this book was available on the Internet Archive (archive.org). E-versions of technical books is one reason I was comfortable getting rid of so many of my technical books (see future purge post).

The Microsoft C 5.0 Quick Reference Guide. This is an actual picture of my copy because I could not find a stock photo. Note the cup stains on the cover. It was a C reference, the page I used the most for C were the escape sequences for printf (e.g. \n, \r) and the language type ranges (e.g. difference between long and float). I still use this reference occasionally for the last table on ASCII codes - the decimal, hex, and character representation of 0 to 255. If you have seen The Martian, then you know.

The Intel 386 Microprocessor Hardware Reference Manual. Yikes, I am not sure why I am hanging onto this one, I have not used it since the time when I needed it. I have flipped through it a couple of time since and seen all the timing and logic diagrams and thought - we actually did this stuff. I primarily used this around interrupts (maskable vs. non-maskable) and for figuring out peripheral timings for external serial devices. We were doing some pretty hard-core stuff at the time. I recall a device we borrowed from one of the hardware manufacturers that sat in between the CPU and the socket. It allowed you to debug at the CPU level and single step through code. I remember we called it the skateboard because it resembled one but have not seen or heard of one since. Hardcore.

It's worth noting that many of the folks I worked with during this time are still friends. We were young and thought anything was possible. On top of that we had a leader who inspired us to live on the edge and accomplish amazing things.

Builders gotta build

When I talk to people about what I like about what I do - there are usually two things that I tell them. First that I like to build stuff and second to solve problems. I am a builder - both in my professional and personal life. Building software is what I get paid to do because I have demonstrated that I am good at it. Building in the physical world is just fun.

Take for instance "building" at home. Fixed things in the house. Upgrades. Or creating something that I need. The one that I wished I had yesterday was a yard tool holder. I recently moved and left the yard tool holder behind. It was something that I built out of extra lumber I had around the house. It looked something like the picture I attached, but custom made for the tools and the materials I had available. I knew what I wanted / needed but was constrained by what I had available.

Sounds like a parallel to building software. There are the requirements and then there is what you can do. The components available and time are both constraints to what you can complete. This is one place where the problem solving comes into play - putting it all together to complete (deliver) something.

There is something rewarding about completing something that I built. Yesterday it was waxing poetic about my yard tool holder. Sounds like an opportunity to consider version 2.

New Coding Problems = Old Coding Problems?

Late last year and into this year (2024) I needed to take time off to recover from surgery. As my mind started to clear but my body was still healing, I started poking around some code. At the time I was playing Pokémon Go (PG) and wanted to build my own mapping application. Well not actually from scratch but build it using a bunch of Python that others had assembled. I was not successful, and it the reason why got me thinking about libraries vs. binaries. 

Library vs. Binary reuse is one of those problems that has been around as long as I can remember. The first time I ran into it was when coding in C (pre-C++) and considering an #inlcude file (.h), a library (.LIB), or a dynamic link library (.DLL). I don't plan on rehashing that thinking now because we all know the right answer and so we can just move on.

The Python code / repositories I was trying to assemble for this purpose suffered greatly from the conflicting version problem. Where code in the same namespace was dependent on different versions of the same library. This creates a Gordian Knot of mixed versions that is very difficult to work out. I am no Python expert, but my understanding from those that are is that this can be a common thing in the world of Python.

Not to give Python a bad name, I know it would happen in Java too. Yes, there are ways to work around this, but I was more focused on getting the solution running that having to unravel dependency tree conflicts.

It was a walk down memory lane that got me thinking that a lot of the old problems I had as a developer are still around. I know the tools have gotten better at helping us manage these and lessen the pain of the problem, but the problem still exists.

The Easy Fallacy

I was talking to one of the younger engineers at work recently and he said that he appreciated my experience. After I realized that it wasn't one of those - your so old moments. I laughed and told him that is probably more true than he realized. For instance, we were talking about an a fix that he labeled as "easy". I told him that in my experience easy changes can be a fallacy. I could see in his expression that he knew what I saying but he didn't know what I was saying.

I can't count the number of times when me, my colleagues, and/or team fell for this one. It looks something like - the change is a small one, often innocuous - like a configuration change. If you're nodding you're head right now, then you too have fallen or been witness to this one.

This happened recently a couple of times. One looked like a change that when merged to to the main branch, inadvertently picked up an unrelated change. This change was not something that was caught until it was promoted to production and resulted in a performance impact. As a result we had a week delay two weeks before the larger launch because we had to do even more work to earn trust that it would not happen a second time.

A contributor to falling for this fallacy is that making simple changes in a complex system isn't about how small the change is - it's about everything else after the change.

Which begs the question, how do you not fall for this one? I feel like this one hurts the most when your under a time crunch and your belief in the fallacy convinces you that you should make "easy" last minute changes. Ouch. Or that you let your guard down on the "easy" change and miss something. The answer for these two is - don't do this. I am sure you have your version of this. 

It works on my machine

One truth I had to come to terms with earlier in my career was the "it works on my machine" anti-pattern. It's a close cousin to the name of my blog - sometimes words DO mean something.

This was back in the days before Windows (yes there was such a thing) and I was writing a custom TSR (terminate and stay resident) module that we used to communicate with the custom database engine we wrote on NetWare (starting to get a sense of the decade yet?). Long story short there was a problem with the code that prevented it from working on one machine - just one. And it wasn't like it always didn't work, it only didn't work sporadically.

In my arrogance at the time, I was slow to take a look at this issue. My arrogant thinking went like (1) this is the only machine to have the issue (2) I spent a lot of time on this code and especially testing it (3) this code has been running on hundreds of other machines without an issue (4) so it must be something particular to the machine or user. Fast forward a couple of weeks and surprise a couple more people report having the issue. It was then that a colleague and I were talking, and I woke up from the spell - "this is something I need to look into" I finally told myself.

Turns out the issue was an interrupt conflict with a badly behaved driver that was slowly be rolled out in a pilot and very soon would release across the entire org and would impact my, now thousands, of customers. Once I figured this out (which was actually pretty hard to do) - the fix was simple; I just switched to a different interrupt. There were other times when I fell under the spell of my own perfume, each time learning something and making me humbler.

Computers and software have grown much more complex since then. developers have much less control over all the code they are dependent upon. In the example above, I was dependent on the CPU microcode, the BIOS and MSDOS - all of which I had the source code for. I could usually discount the microcode (I only recycled the manual last year) which meant that any issue was either with my code or the few dependencies I had. The lack of dependencies and illusion of control was part of where my arrogance came from. But today there are dependencies on dependencies; it's such a complex ecosystem. And yet developers still have quite a bit of arrogance. 

Why am I writing about this now? This time I was the one user for which the application did not work - last year (mid-2020) it started, and I would constantly send logs and traces to the development team, and nothing would happen. I told them that my fear is that my experience was the "canary in the coal mine" and that either (1) other people are also having the issue and not reporting it OR (2) that at some time in the not-too-distant future it would become more urgent. 

The later was this week.

It now works on my machine.

What do you call the people you write software for?

For most of my career I have referred to the people who I write software for "users".  It just made sense, they are using the software so they are users?

Interestingly enough at Amazon we call them customers.  Not to say that the word user has been stricken entirely from the vocabulary, but it makes me wonder if it should.  Here is my thinking.  Something different happens in my mind when I think of the people I am writing software for when I use the word customer.  It is hard to describe...but maybe this story will help you understand what I mean...

When I worked at Microsoft I worked in the consulting division and we would help people make sense of the variety of ways to write code on the Windows platform.  Often times some of my customers (aka clients) would have come up with a unique way to solve a problem using some piece of Microsoft software.  When I would relate this back to the product team (another aspect of my job).  More times than not the question I would get back would be "why would they do that - that is not what we intended".  We used to refer to this as the RDZ - reality distortion zone; which was the invisible field that hung over Redmond that prevented the product teams from understanding how people really used Microsoft product.

When I think about how a customer centric Microsoft would have been different - then the response back to me would have been something like "that is really cool, we never thought of that - how can we make it better".

Try it.  It may just change the way you think about things.

If you smelt...you dealt it

No this entry is NOT about flatulence.  Ironically, there is a Wikipedia page that is - here.  Instead my intent is to opine on the practice at my employer about developers supporting their own code - which means that if you broke something then you are going to be the one to fix it.

When I was managing the production support team at my previous employer; the team's responsibility was to focus on the operation of key systems and ensure that they were available and meeting SLAs.  This team did a good job at keeping things moving - if something broke they got to be pretty adept at fixing issues.  If you look at this as an outcome with a fixed cost (which is how we structured it) then it can look pretty attractive.  But in the end the people on the team had many concerns/issues/complaints/etc about the challenges they faced in sustaining this model.  In the end - I feel that this model takes too short of a view of life cycle of a system and therefore is flawed.

First it is worth noting that Amazon has a list of core leadership principles that they live and breath by.  I have done a lot of chin rubbing around these as of late and the more that I play with them the more I like them.  When considering this post there were a few in particular that I felt applied..."Ownership", "Invent and Simplify" and "Insist on the Highest Standards".  If you read the short descriptions for each of these they are all pointing to how separating support from development is flawed.

If developers are not responsible for keeping their own code running or seeing how it behaves in production then how they doing any of these things?  Sure it is possible that you get outcomes in this direction; but it is not likely - especially without the ownership.

A related topic to this is how we work this into our Agile methodology to ensure that we still get things done on time.

Firehose Treatment - Open Wide

I needed to take a short bit of time off from blogging while I worked out the details of interviewing, negotiating and relocating (at least me) to Seattle from Connecticut.  I am now into my second week of work at the largest online retailer and the fire hose is blasting full force.

Being this big means that someone has already done a lot of thinking about how to make something massively scalable.  Back in "the day" I remember pouring over the Principles of Transaction Programming book by Phil Bernstein.  I knew this stuff inside and out and it still serves me.

 

Given the massive need for scalability I have had to dust of some new/old theories. ACID is out BASE is in.  Sure I have read about a bunch of these over the last few years, but it is different being at a place that is actually doing it.

Here is a list of things blowing my mind today...

1. Eventual Consistency - It will get there when it gets there.


2. Anti Entropy - Anything with the word entropy in it I find confusing.  So what is Anti-Entropy? :-0


3. AWS - I had to pay for this before, now everything we deploy is already running on this.  Note to self; shutdown my services and save a couple bucks.

Interviewing

I was recently helping some colleagues think about interviewing techniques. I like to see work product from people. So, a while back I developed an assessment that we use. It has been a big help in evaluating candidates. It was incremental problem where each step was a question that led to a larger solution. It wasn't perfect, but I got to see some evolution of thinking. 

When I worked at Microsoft we took our interviewing very seriously. Certainly, there are lots of stories (myths?) out there about the process. Some truer than others. I have a master list of good questions and suggestions I still find helpful to review to get into the right mindset. I avoid the "Mount Fuji" questions since they just don't give me much useful data.

Along these lines...I was recently turned onto InterviewZen. I like the idea of being able to watch a recording of someone creating a work product. We have a classic computer science sort of problem (weighted graph) that I use, but I don't get to see the person working thru their thinking. I am going to try and adapt mine to this format.

Keep It Simple (kiss) Revisited

I have a calendar from a vendor we use that has some of the classic coding and design principles - one for each month.  I was rubbing my chin staring at it this morning and I wanted to share what popped into my head...

While I am sure that the KISS principle has been written about (perhaps to death) I had another instance of this today as it applies to operations and infrastructure.

Quick background - I recently inherited an Operational group.  Operations is the clean up crew of development here.  While I understand the rationale of separating them, I think I like the idea of developers supporting their own code so that they better understand the impact of what they do.  What a great teaching tool - you want to not get up in the middle of the night - fix the code, do a better job in the first place, write a utility to help you out.  We have a bunch of applications that have been around for years and over time the developers who maintain many of these have moved on.  So today I asked the question of someone about two AD groups and what they are used for.  In both cases the answer was initially I don't know - and later the answer became these are not used anymore.

Part of keeping systems simple is getting rid of the things that are not used anymore.  We have all these extraneous moving parts that we don't need.  This just creates system bloat that should be easy to remove.

Granted you cannot get to everything - right now.  But this stuff has to get cleaned up over time.  Putting it into some sort of maintenance, wish list or Kaizen log seems like an easy thing to do.

All it takes is discipline.

Agile Musing

I was at a LOMA meeting for work last week and was talking to a couple of other attendees about their Agile practices.



It reminded me of some early thinking I was doing back in the 90's.  I was always drawn to doing things in what people now call an Agile way; but the first time I heard someone actually put words to what I was thinking was a presentation Jim McCarthy did at the 1995 Microsoft Global Summit in San Diego (I think).  I used to have the video on tape but it seems to be long lost at this point.  I found a couple YouTube excerpts but not the who thing.  He went on to write his book Dynamics of Software Development which elaborated on his 21 rules (I think the book has 40 something).  I remember liking his style...oh yeah...and the content was good too. :-)

The Pragmatic Programmer is another book that put more meat on the bones of things that I was thinking or struggling with.  I consider this a timeless book unlike the Peter Norton's Programming Guide to PC book (the pink shirt book) I recently came across in my archive.

As I reminisce I am reminded about the Agile Manifesto which at first made me laugh but after that tickling feeling passed I took the simplicity and truth of it to heart.  I attached the image I keep on my desk here for posterity.



Not sure what the next Agile is going to be.  I do feel like there is something still missing that  I can't quite put my finger on.  Hmmm.

Things that were once hard

I needed a quick utility to generate a script for setting the permissions on a massive (wide and deep) directory structure.  The analysis for this was not going well - I asked someone else to try it and they did not get the scope of the issue.  I needed to just get something running quickly so I wrote a quick .NET app to generate what I needed.  I was pleasantly surprised when went to actually grab the permissions for a given folder.

The last time I did something where I was scraping permissions off a folder I was in C++ and the Win32 API.  Yikes!  High impedence for something that I was just going to throw away.

The following is a snippet of code that wrote doing in .NET 4 (I don't think this code would be any different in .NET 2).

 class FolderPermissions  
 {  
   public string Name { get; set; }  
   public IEnumerable<Acl> Acls { get; set; }  
 }  
 class Acl  
 {  
   public string Name { get; set; }  
   public FileSystemRights Permission { get; set; }  
 }  
 private static FolderPermissions GetFolderPermissions(string pFolderName)  
 {  
   AuthorizationRuleCollection perms;  
   perms = SafeCallToGetAccessRules(pFolderName);  
   var retAcls = new FolderPermissions { Name = pFolderName };  
   var acls = new List<Acl>();  
   foreach (FileSystemAccessRule perm in perms)  
   {  
     if ( perm.AccessControlType == AccessControlType.Deny)  
       continue;  
     var acl = new Acl() {Permission = perm.FileSystemRights, Name = perm.IdentityReference.ToString()};  
     acls.Add(acl);  
   }  
   retAcls.Acls = acls.ToArray();  
   return retAcls;  
 }  

This snippet is where I am copying the permissions for a given folder into my own lightweight structure, so that I could do queries on the structure to help me create the script.

One thing in particular I remember about doing this in Win32 was once I got the SID for a particular identity, it was a pain to resolve that to a name.  Now it is just the IdentityReference.Value.

This is the type of value I like.  Now if I just had a scripting language to do this in so I did not have to compile it would be all set.  Of course there are bunch out there - just I am not as proficient in them as I am in C#.  Hmmm.

IIS 7.5 and 2 Level Auth

We use a large vendor application at work.  We host all the infrastructure for the application inside the firewall, so there is absolutely no access from the Internet.

In IIS6 we configured 2 level authentication - NTLM and Forms Auth.  The vendor requires Forms Auth for the application.  Given the importance of this application and sensitive nature of the data; I also enabled NTLM and secured the site to only people in our division (about 450 people).  There are about 150 logins in the application meaning that 300 people have access to the site; even though they will not be able to actually see any screens until they login.

Through a series of discussions with different audiences; it was decided that there is still enough of a risk of those 300 people being infected with something that takes advantage of cross site scripting or other classic vulnerabilities.  So I further locked down the site using a more restrictive group.  While I feel like we are being a little paranoid about, I capitulated.

Enter IIS7...



Our standard for servers is Windows 2008r2 so we are on IIS7.5.  Doing this same 2 level authentication on IIS7.5 did not work.  Why?  Well because of the integrated pipeline...it simply cannot not do both at the "same time".  One has to come first.  In IIS 6 NTLM always came first since that was done my IIS and then Forms Auth since that was done by ASP.NET.

There are a couple of hacks out there that describe how to work around this.  One of which I found posted here by Mike Volodarsky (formally of the IIS team).  Here he talks about a way to make this work by splitting up the authentication and forcing one to happen before the other.  I was up until well after midnight last night trying to consider how I would make this work given that the application is a vendor application and I don't have the source code.  Not to mention that everything is precompiled, signed and obsuficated.  All of which add up to...this would be really hard to hack.

Finally, after a bit of chin rubbing...I came to the conclusion that the integrated pipeline may not be the problem at all.  Why do I even still need NTLM?  I mean if the only way for someone to access a web page on the site is to have a valid Forms Auth token then do I really need to force them to also have an NTLM token?  I went to bed content that I just need to leave NTLM behind in this case.

Now I just need to convince everyone that was pushing the original requirement for 2 level authentication that I don't need it anymore.  Being that they don't really understand the technology very well - that could be a challenge.  Since the way we got here was through a vulnerability scan of the web site in the first place - perhaps requesting another one will demonstrate my point and I won't have to make them understand the why.

I will post an update on the outcome.

TFS Recovering Shelveset for Invalid User

One of the developers on the team was getting a TFS error (below) yesterday while trying to access a shelveset for a developer who left the account a couple of months ago.  Turns out he needed some of the code on the shelveset.

 TF50605: There was an error looking up the SID for TC30014  

Note to self...shelvesets are probably not the way to do this, thinking that a branch would better construct.  I want to encourage them to be doing more of these anyway.

The problem is because TFS is going to lookup this user in the Active Directory and the user does not exist anymore.  I can see the shelvesets in TFS using either TFS itself or TFS sidekicks.  I included a screen print of all the active shelvesets for this user in sidekicks.



So TFS must be doing some lookup on the user and when it does not find it - errors out.  Not knowing how to solve this, I put couple of searches later ("tf50605 -vssconverter") out there and found this article.  While not directly what I needed it was enough information to crank up SQL Server Management Studio and start poking around a bit.  So I started with the OwnerId for user that was removed and for the user who was trying to get the code.

 SELECT IdentityId FROM tbl_Identity WHERE (DisplayName LIKE 'ad2\TC30014')  
 SELECT IdentityId FROM tbl_Identity WHERE (DisplayName LIKE 'ad2\RMxxxxx')  

Once I had this I plugged the deleted user's id into the following query to get all the workspaces.

 SELECT TOP 1000 [WorkspaceId]  
    ,[OwnerId]  
    ,[WorkspaceName]  
    ,[Type]  
    ,[Comment]  
    ,[CreationDate]  
    ,[Computer]  
    ,[PolicyOverrideComment]  
    ,[LastAccessDate]  
    ,[CheckInNoteId]  
    ,[DeletionId]  
  FROM [TfsVersionControl].[dbo].[tbl_Workspace]  
  WHERE OwnerId = 276  

This showed me a bunch of workspaces.  What I noticed is that evidently the shelvesets and workspaces are used in a similar model based on the type.  So a little bit of infering and playing in TFS and it looks like if I hack this table, I can reassign all the shelvesets to a valid user (which is sort of the spirit of the article above).

Leaving out some of the details, I ended up with the following query that reassigns the orphaned shelvesets (type=1) from one owner to the other.  Since the WorkspaceName is part of the primary key (and relatively short), I changed the name so that the new owner could distinguish between his shelvesets and those that were reassigned.

  UPDATE [TfsVersionControl].[dbo].[tbl_Workspace]  
  SET OwnerId = 123,  
    WorkspaceName = RIGHT(WorkspaceName + '-Reassigned',64)  
  WHERE OwnerID = 276   
    AND Type = 1  

Looking back at TFS Sidekicks (I verified it first in SSMS - wink) I could see that the more recent shelvesets had indeed been reassigned.  Sucess!!



Now granted, we are on a relatively old version of TFS; so this hack may already be obsolete. But I wanted to put it out here just in case.

Step Away From the Keyboard

My career has been undergoing a sea change lately. I am doing much less programming and more SharePoint. Not just SharePoint as a technology but applications/solutions built on SharePoint. Sure I may need a little code to pull something together, but not as much as I once was writing. Not to mention that I am being asked to take on more management responsibilities. On one hand this feels like a bit of a “promotion” on the other hand I feel myself slipping further away from the truly technical side of things. Which is kinda scary.

Up until the last year or so; I have been pretty technical. But now I find those MSDN magazines piling up on the nightstand. I just read some of my favorite programmer blogs and just scan the code. Sure I understand what and why these guys are doing, but I am not doing it myself. I used to be coming up with patterns like this myself and now I just read about them.

Being technical is a great security blanket; don’t like what your doing or where you are doing it? Just leave and go someplace better.

It does not feel like that now; things are starting to pass me by. Ouch. It’s chilly without my binky.

Since I have a lot to learn in this new role, whatever you want to call it; I will probably have to be with my current position for some time while I figure out the patterns for doing this job. Doh! What do you mean I can’t leave? I have to stay and learn this stuff no matter what? Doh! Doh!

PowerPoint Linking to Excel Issue

When updating a link (right click Update Link) or editing a linked object (double click on the object) in PowerPoint the user receives a dialog box (shown below) stating “The linked file was unavailable and can’t be updated" . Here is a document I wrote that describes how to fix this issue. We encountered this issue in Excel 2007 sp2.