pjbster

Not that these execs would see it like that. Instead, they hear this Scrum thing has worked wonders elsewhere so they wheel it in and, if it fails this time, it's clearly the crappy workers who are to blame. "Management was right about that all along."

I take other commenters' point about strong leadership making a difference. Fully agree with that. But some situations are simply unrecoverable no matter how great the team.

Then see how the bottom line fares. I see three outcomes:

  1. Profits are down. Those managers added value after all.
  2. Profits about the same. Those managers added nothing.
  3. Profits up!! Those managers were dragging them down the whole time. Who knew?

When organisations are formed of people with perfectly aligned incentives, they don't need to be managed. Such people know what needs to be done and have the expertise and autonomy to make it happen.

Of course, such an organisation is hopelessly unlikely to retain this utopian state as the number of employees rises above 2. And it becomes vanishingly improbable if outside funding is involved.

So management is the act of taking care of something which can't take care of itself. A symptom: like an antibody, it arises when a system gets of out whack and its continued presence indicates a chronic condition.

The best thing management can do is to put systems in place to make itself redundant. So, by this definition, anything it does which promotes the opposite goal is a mistake.

Volume 4 issue 4 introduced the Alpha architecture and includes an article describing the effort to port OpenVMS: http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pd...

It shouldn't be hard to identify those voters; I always have to hand my voting card to someone when I go to a polling station so I imagine there are lots of lists somewhere of people who were registered but didn't turn up.

Living healthily is really, really simple: if it comes in a packet, don't eat it!

Take a look at http://www.marksdailyapple.com/

If there's one thing you need to hang on to it's this: no matter how starving you feel, you're not going to die if you don't eat something! Your body can go for three weeks and more without you taking in anything more than a few glasses of water each day.

In other words, if you can't eat something natural, don't eat anything at all.

You. Do. Not. Need. That. Snack.

(Personal anecdote: I trained for an ultra endurance event a couple of years back and used to set off on 100-mile rides without eating breakfast first. Once your body adapts, you'll be amazed at how little you actually need to consume to really feel alive.)

Here’s one example:

* Moving functionality from a legacy^2 to legacy (mainframe to client-server)

* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.

* Source and target systems inherently un- unit testable

* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some

* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories

* Culture of fear reinforced by performance reviews, stack ranking and PIPs

* Locked down QA systems and silo’d resources

Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.

If the discussion can add more value than those costs, then go for it.

Clean air can't come soon enough to London.

It's not hard to find a variety of diagrams purporting to illustrate how the myriad management functions in ITIL fit together. You'll see lots of silos with names beginning with "Service..." this and that (because, in a massive injection of double-speak, IT likes to describe itself as a service rather than what it really is: a racket).

Here's a typical example: http://www.itsm.hr/brosure/ITSM_CHART_V2.0.pdf

I dare you to find an appropriate place in this diagram to place your dev team. Pity the poor CIO: not only does he/she have to decide whether to buy or build but the build option comes with strings such as also having to invent a management process to go with it!

So, again, most "Service Design" managers don't bother: they just hire the nearest TOGAF-certified architect team and hand over all development to them.

It's hardly surprising that corporate dev team managers often find themselves in the role of "supplier", on the outside looking in. No-one with ambitions in the organisation wants the job and anyone who ends up in there has probably done something wrong or emerged as a natural also-ran in previous political games.

What this means to devs (particularly) and some testers (depending on which box they live in) is this: They Are (so) Fscked.

I saw my role become disenfranchised over the course of 6 years as a result of a regime change which imposed ITIL upon us. I avoided suicide by jumping into the contractor market and, through nothing more than sheer luck, have found myself working for a small autonomous team looking after an important business function (worldwide royalty payments). My boss has a rebellious streak which I strongly identify with and she also has sufficient career capital to keep her team identity intact.

I'd like to leave IT and do something which delivers more personal self-worth (pimp or drug dealer at a minimum; international arms dealer if I just can't do without the Bond lifestyle) but I need to clear some capital debts first so it's contracting for the next 5 years or so. Beyond that? I'm just hoping there's still a world left to walk out into.

(I got asked this very question by an American relation a few years back.)

Interesting. Seems to advocate for shared office space and interrupting co-workers (later in the same paragraph).

The author clearly feels that there was a synergy there and doesn't presume to claim any wisdom as to why this was the case.

So we're left to tease out our own conclusions: keep team sizes small, cross-functional and in shared office space.

Interesting choice of word: "escape". Not: "fix".

From experience, said process cost waaaay more than 0.5% of the budget. Time and cost overruns, massive overhead in personnel and a drain on mental resources which should have been spent on actual release quality rather than an audit trail meant to convey "Certified" quality. All in all, I'd say 50% of the costs of IT delivery were spent in plodding through the checkpoints with much of the other half being consumed by the interest on 20 years of technical debt accrued as a result of those very same resources being misdirected in such regulatory endeavours.

I recognise than I'm far too cynical to see regulation as anything other than a shield against liability. It's simply too obstructive to contribute to actual quality improvement. On the plus side, it does keep about 50% of IT personnel in a job.

So I guess you can count me in with the lovers :-)

In the end, there's only one rule that counts: spend less than you earn (or earn more than you spend - either way, you need to have control over at least one of these variables or you're totally fucked anyway).

Sorry to be so blunt. Of course, some people like the process of keeping on top of statement reconciliation - hell, I used to be one of them. And there's no doubt that watching your net worth increase will bring pleasure to your day.

But it's easy to become obsessed. It's only now that I've surrendered the "comfort" of knowing where my money went that I realise I was actually stressed out all the time. These days, I'm a little more relaxed about things - so long as we stick to normal spending patterns and don't splurge on spontaneous things, we'll probably be ok.

In my case, I can live with this level of uncertainty. Ignorance is bliss, and all that.

(I'll echo the other sentiments around here: YNAB was my favourite. I never tried Mint.)

I usually stop behind the lead car at traffic lights to avoid this; I can usually keep pace with cars (in London) but flaunting this by trying to race them away from the lights is just asking for trouble, not to mention more physically taxing.

So... if I'm on the front of a queue and can safely move away before the lights turn green, I'll do it because it puts distance between myself and the lead car, giving the driver more time to line up a safe manoeuvre around me once the traffic starts moving.

This has to be weighed up against the very real danger that the drivers will be fuming with rage at the arrogant cyclist in front and thus losing the senses of calm and serenity that I'm trying to spread :-)

https://www.theguardian.com/cities/2015/oct/27/cyclists-run-...

Johnson and Transport for London requested permission for a trial back in 2009, but it never took place. TfL has concentrated instead on remodelling junctions to allow “early release” (where cyclists get a green light before cars) and “hold the left-turning traffic” (keeping cyclists and cars apart on left turns).

For me, Scrum has always been nothing more than an “Agile Bootstrap”. The core idea within it is very simple: try something and examine the results. Stick with what works and try alternatives for what doesn’t. Repeat. And, above all, learn.

So Scrum starts you off with a list of practices to get going with. The whole litany of backlogs, story points, sprints, daily stand ups and retrospectives is nothing more than a vocabulary - a pattern language for stakeholders. It’s got pros and cons - a good way to bring people together but it needs to be recognised as a crutch and ditched quickly before the team comes to treat it as an article of faith to be defended at all costs.

And this is where so many agile coaches fail in my (limited) experience. When I was undergoing scrum training, it was hugely disappointing to hear colleagues asking questions of the trainer along the lines of “Can a scrum master multi-task among teams like an anaesthetist in a hospital?”. Or “What does Scrum advocate when a production incident requires someone in the team to drop out and assist?”. Or “Can we have scrums of scrums?”.

The answer in every case is the same: try something - anything. See how it goes and decide whether to apply that approach again in future.

Time passed. I was tasked with rewriting a fairly complex piece of code and I put the new code behind a feature flag. At the time, there was no facility in place to support feature flags so I had to introduce one as part of the deployment. It all went into a test environment but the deployment scripts didn't set the config to enable it. This was deliberate because I wanted to verify that we wouldn't change existing behaviour (i.e. break anything) by deploying with the flag disabled. The testers, however, were looking for the new functional behaviour and raised a defect.

- when the project manager found out, he claimed that this was responsible for a timescale slippage (the delivery into test was massively late, naturally)

- when my line manager found out, he told me I'd be fired if I tried a "stunt" like that again

- when the DBAs found out, they decreed that, henceforth, all database updates which resulted in a "functional change" would be subject to the full release process (i.e. cold backups).

So the experiment was a total failure. Or a total success. It depends on how you look at it; one amusing moment was when the PM came out of a meeting and, with some gravitas, suggested that we might have to rip out half the new code in an effort to salvage the timescales. When I demonstrated that we could achieve that in, oh, about 5 seconds by flipping the flag, the notion went away. The guy was a contractor and I suspected he was just trying to create more work to keep himself around.

To me, the biggest question with feature flags is managing the removal of dead code. In this case, it was never removed because the task of deleting it would trigger a full project release cycle and the company didn't see the point of spending the money.

Most of the time, the code I work with operates on a handful of records per transaction; bulk operations require entirely different tradeoffs and I don't have much to offer here.

All of the problems I've seen stem from the understandable urge to treat the database as a giant global variable. Oracle provides a myriad of conveniences to facilitate this from within pl/sql so developers do exactly that:

- In the middle of some logic and realised you needed another piece of data to work with? Just splat another inline SELECT in the code and move on.

- Want to update a table but you can't find an existing SP which writes what you need? Just splat an inline UPDATE in the code and move on.

Over time, these SQL statements littered throughout the stored procs become a complete mess. Another issue is that client code is often given unfettered access to the base tables. If those tables don't force data integrity either by constraints or triggers, then god help you if you want to update any column anywhere in your database: you simply cannot know which clients may break.

Oracle pl/sql offers both FUNCTIONs and PROCEDURES and these form the core of a number of idioms I've come to recommend:

- if your pl/sql performs any side effects, it's a PROCEDURE. End of.

- FUNCTIONs never contain side effects (or use OUT parameters).

- PROCEDURE status is "toxic": if a FUNCTION calls a PROCEDURE, it must also become a PROCEDURE.

- client code never accesses base tables. Wherever possible, try to provide access through a package API: instead of SELECTs, call functions which return REF CURSORs, instead of UPDATEs and INSERTS, call PROCEDUREs. These mechanisms are all supported by both jdbc and .Net though you'll have to do a bit more work.

The key thing is to put your BL in functions, not procedures. They're much easier to test, especially if your variables can be passed in as parameters rather than being lifted from tables via the seductive inline SELECT option.

PROCEDURES are always tricky to test. Try to keep them as simple as possible and try to minimise conditional logic leaking into them.

Data integrity is difficult to get right. Oracle provides table constraints and triggers but beware of putting BL into either of them (the dividing line is often blurry and the risk is that your future applications may be overly constrained whilst your existing ones may come to rely on leaky assumptions if you relax the integrity guarantees). I've not seen constraints or triggers used to great effect anywhere, to be honest. Most shops avoid them, it seems.

The easiest way to stay on top of data integrity is to force all updates through higher level SPs. Don't let clients touch base tables and, instead, force them to call facade packages. Write one facade package per client - Oracle will mark the package as invalid if you modify anything in the execution path of said package and this provides a valuable tool for impact analysis.

CI is nearly impossible in a live database unless you're running a version of Oracle with Edition Based Redefinition. The only alternative I can think of is pulling your logic out into middleware libraries.