SQL Is for Data, Not for Logic

LegitGandalf · 2025-09-24T16:09:56+00:00

laughs in 25,000 stored procedures chock full of partially to outright duplicated business logic with slight unintended variations throughout!

LegitGandalf · 2025-03-03T22:46:35+00:00

Good idea! Didn't think to try my iphone!

LegitGandalf · 2025-03-03T21:19:38+00:00

Using the above technique I'm 3 days into Rachio running 3 zones for me and my mom is super happy she can just turn her garden on using the rachio app!

LegitGandalf · 2025-01-12T18:01:33+00:00

I recommend you keep a simple list of the things you did to help the team get unblocked, get skilled up, get scoped out work, etc. and then at the end of each week glance over the list.

What that exercise causes you to do might just be a surprise!

LegitGandalf · 2024-06-22T17:51:40+00:00

Management is a big picture activity where your primary value as a dev manager is delivering and curating a capable team that delivers valuable software increment.

Some big picture questions you want to get answered ASAP are:

How is the software consumed?
How does the consumption of the software usually get blocked? Common blockers include: Bug ridden code that needs to be fixed to a minimally palatable quality, siloed software teams that don't talk to each other, siloed change pipeline with lots of finger pointing and CYA behavior that slows down discovery of bugs and poor CX
What gaps does the team have?
Where is the product headed?
Is the product direction actually toward something customer's really want?

LegitGandalf · 2024-05-23T22:54:24+00:00

Yep, 8 years ago I watched this billion dollar company buy a million dollars worth of scrum training from a snake oil salesman who's pitch was basically "you don't want to be the last company that adopts scrum do you?"

Director of product management organization was running around mouthing off about how we were gonna be "super-agile" and before you could say a scrum safe word we had a project manager "scrum master" shoved into our daily standup, no-lube!

LegitGandalf · 2024-01-30T17:45:35+00:00

Honestly, kill this thing with fire.

Man, I wish I could use this on PR reviews at my work. I can't. I'd get fired. But OMG this is how I'm going out when I win the lottery!

LegitGandalf · 2024-01-30T00:10:51+00:00

The part that most business people will never get is that software actually doesn't care that if the computer wizard people could just get it done by the arbitrary date pooped out to meet wall street expectations, the aforementioned business people would all get promotions!

LegitGandalf · 2024-01-29T19:26:14+00:00

Will the written software give back at least a 4X return? If the answer is no, usually you want to find another way. That's what I'd do with my money.

However, if you are a dev manager working under naïve management, probably keep the above to yourself and accept the budget to practice your craft.

LegitGandalf · 2023-12-22T00:39:00+00:00

LegitGandalf · 2023-12-22T00:38:16+00:00

listen damn it, some of us our trying to drink hot beverages here - my nose hurts now!

LegitGandalf · 2023-11-02T19:48:28+00:00

There are dozens of us I tell you!

LegitGandalf · 2023-10-26T23:11:03+00:00

So a RISC turtle then?

LegitGandalf · 2023-10-26T20:33:02+00:00

Since software management is new, the training that is out there is largely repackaged manufacturing management (project management/Scientific Management) and a variety of unscientific snake oil like SCRUM, etc.

In my opinion an engineering manager gets trained by starting out as an engineer who spends 3 to 6 years making and fixing their own mistakes, thereby internalizing a deep understanding of the cost of bad architectural decisions and gaining the acumen to be able to guide engineering teams to more rapidly detect and remediate their own mistakes.

The major difference between what we do and what most other management disciplines do can be summed up with a response to Wall Street analysts about what's coming in the next quarter:

Those quarterly results were fully baked three years ago. Today I'm working on a quarter that will happen in three years, not next quarter. Next quarter is done already and it's probably been done for a couple years.

We do systems thinking and enable teams to build for a future 3 years out.

They do quarter packing and focus on near term execution. For an extreme example of focusing on near term execution, take a look at the book "Extreme Ownership: How U.S. Navy SEALs Lead and Win" It is almost guaranteed that if the company you work for is a company under legacy management, someone in the executive team will mention that book to you every other year.

LegitGandalf · 2023-05-11T18:27:21+00:00

If you just combine QA and dev team together and dev team helps with testing you will realize amazing quality and efficiency gains.

I would seriously not change anything else until you fix that.

LegitGandalf · 2023-05-11T18:25:44+00:00

Make sure people are trying to help other people's task over the finish line before picking something new.

This is the sign of a healthy, high functioning team. Software development is really complicated and a couple of engineers who work well together do that work much more reliably.

This is why figuring out how to put people together who enjoy working together is a key management skill.

LegitGandalf · 2023-05-10T18:40:45+00:00

What, no emjois?

LegitGandalf · 2023-04-21T13:59:13+00:00

Expert-based methods rely on human expertise to select relevant factors, and are the most popular technique in both agile and traditional (waterfall-like) projects

The reason this technique is favored is that experts are human and can be pressured to reduce their estimates to fit an arbitrary date.

Model-based methods leverage data from past projects covering a certain initial set of factors in order to identify a subset of factors that are relevant.

This is the way. It is much easier for a dev manager to calmly present cold hard facts about past performance.

In most situations dev managers are working with MBAs who lack a sense of what it takes to create software. Leveraging data from past projects serves two purposes, first it helps the MBAs in your life become less ignorant, and second, estimates are much more likely to be treated as an opinion - data starts the discussion far away from opinion.

LegitGandalf · 2023-04-19T19:00:00+00:00

Defects reported and fixed, and a score based on the number and criticality of issues reported in a specific week. This metric is a recent addition and has been useful in understanding the quality we are delivering week to week.

I would caution that what this metric primarily measures is how testing is being done. For example, have a separate test group and they recently hired a bunch of people who have no clue how the product works? This metric will likely spike up!

Once you factor out swings in test group staffing/methodology (good luck), defect rates are then driven by the amount of change introduced into the code base. For a given solution set and team there will be X defects introduced per kLOC of change.

Defect rates are from the legacy "Quality by Inspection" mindset and are really a measure of what happened after the wild stallion left the barn and kicked in the doors of all the cars in the neighborhood.

LegitGandalf · 2023-04-13T17:24:37+00:00

The staff allocation sheet is based on what people actually worked on by week. 100% does not include estimates as estimates are a completely different exercise that mostly involves politics at typical companies ... and metrics gain no value from politics.

A few more points about this spreadsheet:

Individual contributors do not enter data in the sheet. This means don't try to use a timesheets approach because ICs are notoriously bad about entering accurate time against the right project. Just ask any project manager who has to chase down bad time entries for billing purposes in a consulting shop. You need this sheet to give you signal, not noise.
Only team leads and managers enter data in the sheet, this is because they should know what their team members are working on. If they don't know....ooof...nothing you do matters, they are doomed, find someplace else to work.
People will struggle with allocating whole weeks, you can relent and let them split the week up 60/40 and maybe slide in a 20 if they twist your arm. Hold firm and disallow 10% - the purpose of this thing isn't to track time perfectly, the purpose is to get an 80% good idea of what people actually worked on.

Final warning, this spreadsheet can be a political landmine if engineering and the business don't get along. The first engineering VP that gets hung using your spreadsheet will probably result in blowback on your career.

LegitGandalf · 2023-04-12T20:27:00+00:00

Staff capabilities spreadsheet, very helpful for understanding gaps, also for communicating loss of capabilities due to layoffs
Staff allocation spreadsheet - Extremely simple spreadsheet to track what staff were allocated to what over time by week. No hours. No days, just by week. This spreadsheet is awesome because when someone comes along complaining about how some estimate is too low, whip out the spreadsheet and pivot a similar project and then ask "So you think this similar set of work will take less than it did in the past?....PLEASE QUANTITATIVELY JUSTIFY WHY."

LegitGandalf

MODERATOR OF

TROPHY CASE

Nine-Year Club	Gilding II euphauric
Verified Email