'Treat your developers like creative workers – or watch them leave'

Seconded

I tell people that as a BA, my job is to pester the hell out of the business by acting like a toddler; just ask "Why?" over and over.

Nothing bothers me more than being handed a "requirement" that says, "I want a new checkbox on this screen that someone has to tick in order to click submit." Besides possibly being bad UX something that isn't typically part of the UI, there is an underlying issue there that isn't being properly voiced. Did Legal come by and say this action requires a second confirmation before it can be completed? Is the Call Center fed up with people calling in to rescind an action they took? Perhaps Operations is tired of some orders being incomplete.

All of these are legitimate business problems and need to be resolved. But the problem more often than not is the person requesting is a SME in that particular flow or function, but doesn't know how it fits in the larger picture. So I sit down with them and figure out what's really going on, what really needs to be resolved, then I get with my developer(s) and we talk about proposed solutions.

To be fair, I've worked with a few Devs who just want to be told what to do. They can't stomach JADs or other solution sessions, don't want to spend time in a meeting with a few other people tossing around ideas, etc. But I've found that even the most adamant "just tell me what to do" Devs like to have input at some point, even if only to say that they think the checkbox should be a radio button, and give a reason or two why.

I've often found the 'problems' that they've encountered aren't actually problems at all, but rather a bullish way to add a 'feature' they want, which is why when you offer alternative (better) solutions they often get shot down.

Re: Agile makes us cogs

Everything takes longer, for more people, and - more importantly for me - it isn't fun any more.

But the PHB's and MBA's love it because they can micromanage everything. One so called manager I encountered wanted to know why I didn't ask his permission to stop my current task and deal with a P1 problem at a customer. At the time, said manager was skiving off down the Gold Course with his other managemt pals. Higher ups thought that they were doing some brainstorming.

Agile was one of the main reasons I took early retirement. I got pissed off with the rigidity of a supposedly flexible (As in agile) methodology. As for SCRUM.... [expletive deleted]

Scrap the lot and watch the productivity go up and along with it employee job satisfaction.

Just my worthless opinion though.

Re: Agile makes us cogs

"Add Facebook to our device"

I quit

Re: Agile makes us cogs

Agile is just another word for letting loads of people fuck up development.

he more people you add to a development, the worse i gets. The more idiots and people who are are winging it join, it fucks up more.

Re: Agile makes us cogs

The worse thing is when you get a highly specified request, do it, then get another request a few weeks later to patch the same area of code because the first request didn't consider everything.

You are unable to do a proper job, and in this trade it's all about job satisfaction in doing something properly because that's really what it's all about. Agile has finally managed to take that away from us.

Re: Agile makes us cogs

The sad part is the real idea behind Agile was an attitude to break down the silos between groups and empower developers and users to actually talk to each other about problems and solutions. The idea is they would have relatively frequent meetings with whoever was needed to keep the project on track. It has been perverted by PHBs and MBAs (and even lower life form) to something else. Uncle Bob Martin has a few choice words about the perversion.

Where I work, it is expected that end users and programmers will talk to each other as needed as the project moves forward. The purpose of Agile but the formalism normally used.

Re: One rule does not fit all

Once business get beyond doing grunt labour, like digging holes in the road, people and their skills and knowledge become less + less fungible.

Not that most orgs of the last 20 odd years have learned any of that, as I arrive and look at steaming piles of sh1t with noone around to actually do the work.

"A cutting edge interior design by the John Frum Partnership..."

I'll preface this reply by saying that I consider myself a "creative" person, and a "people" person, but:

I hate "cool" offices. They remind me of really good mental health facilities. Outwardly pleasant and cheery, but only to compensate for the fact that nobody who is there really wants to be there.

I tend to agree with "pay me more money" but for I'd express it as "let me work shorter hours".

I also don't want free food or soft-drinks - for me, as for many other people, eating is a stress response, and sitting at a desk for long hours to meet a contrived deadline is already bad enough for my health without adding excessive salt, fat and sugar consumption to the mix. Again, I'd prefer to work somewhere where there's good enough management to ensure that going home after eight hours is the norm, with very low deviation from that.

As for furniture, I actually love designer furniture ... in houses, or hotels, or bars, but I really don't need it at work. However, ergonomics is much more important and often forgotten completely in the rush to make a visual impact. I've seen lots of places with "cool" furniture that cannot adapt properly to very short or very tall people sitting at the desk. A pretty office space might be good for morale, but back-pain outweighs it, I'm afraid.

Also, I don't see any problem with people of either sex wearing dresses in work provided that it's what they feel comfortable wearing : a good workplace is one where nobody feels like they're unwelcome, and again that has nothing to do with graffiti-art commissions, in-house massage therapy or Nerf guns (save me from grown men playing with children's toys...).

Too many start-ups adopt a "cargo cult" approach to offices - trying to reproduce the superficial props that they see in good places to work, without realising that those are the (often self-funded) result of employees who enjoy coming to work, not the cause.

Re: Spreadsheets are a stupid answer to whatever the question is.

Unless the question is "What is the point in spending 10 or more years of your like studying software engineering".

Trying to maintain other people spreadsheets in a meaningful way means you never take easy shortcuts that you know will become locked into the system and require you to maintain it - probably on a friday end of month when you are on a promise. I've spent many a long hour writing vb libraries so the accountant can write 'maintainable' code in a spreadsheet ( i.e. call the bloody library routine). Mind you you need a slightly* above average accountant to do this.

*in an exponential way.

"Spreadsheets are a stupid answer to whatever the question is."

I have come to the conclusion that spreadsheets are probably the worst single piece of office software. They allow the mathematically illiterate to play with numbers and find new ways to invoke Murphy's Law.

His comment about 'knowing how to prrogram Excel' is wrong.

What he likely means is "everyone will have a crack at record-macro programming in Excel".

Re: Software Tradesmen

At one point in my career my company made the decision to vary the title of "Consultant" with the alternative of "Consultant Practitioner". The latter title distinguished those with the depth of experience to actually roll up their sleeves and fix the customer's problems.

The difference between a "crafts(wo)man" and a "professional" could be said to be - that the former is often a gifted "amateur" who will deliver a working solution even if the money runs out.

Re: The Mythical Man Month

Along with 'Decline and Fall of the American Programmer' by Ed Yourdon.

Constant re-examinations of current models of software production and their percieved problems followed by suggested solutions (which the advocates then take on world seminar tours).

Personally I'd like to see a serious in depth study on the 'science' of budgeting. How come it's always the project that comes in late and overbudget, and never the Budget that was badly specified in the first place.? With the usual consequence that the infantry get fired, and the budgeteers move on to the next project.

Re: Managed Creativity

"only coding for what is currently required"

Not necessarily a good idea. I've been effectively instructed to code myself into a corner with that approach.

I then watched them having to hack database and code every time a new requirement was added. In the meantime I'd set up the next project which started off by chucking out all the "currently required" code of the first project and replacing it with an open-ended approach that took new requirements in its stride - including being re-used in the project after that.

However, have an upvote for the rest of the post.

Re: Managed Creativity

"only coding for what is currently required"

I remember someone giving a lecture about 30 years ago on their successful use of C++ to implement a checkout (POS) terminal. They said that it was only possible because they had already spent many years in previous developments discovering the vagaries of customer requirements in cross-border, multi-currency, multi-vat rate retail businesses.

They were therefore able to construct their object architecture to cover the possibilities. Otherwise it would apparently have been a tear-down every time when someone came up with a new wrinkle they wanted.

Needs to a C suite - Programming Executive Officer.

Software's eating must corporate functions anyhow.

Re: A pain for sysadmin

"Don't let me get started on letting dev's become sys-devs."

Back in the day we were the (very small) Unix/DB team. Design, develop and manage. That way you didn't develop what you couldn't run and you understood the application level consequences of what you did as an administrator.

Yes, it harks back to the idea that if you were a Unix user you were a C programmer. It might have its downside but has the situation where you had to write a stack of documents to have the system guys release a slab of storage space for the DBAs to add as a chunk to the database engine, a process that seemed to occupy most of the 4 weeks I spent as holiday cover there.

Re: Agreed

You master the syntax which, language depending will take you 6 months (C), never (C++ - moving target).

Then you master where the language fkcups - 5 years.

Then'll you master how other people can fckup an implementation with a language - never.

Then'll you have Zen like lightbulb moment as you realise building any non trivial code base with anything but Makefile/cmdline, where you can archive the build options, build files, tools versions etc etc, is insane. You will then look around he office and see everyone using IDE's where not a single configuraion matches another...

"I just want a job that:"

You want freelancing.

Rules 1->100: Work activity is in company time, according to the contract Ive signed.

I spend enough time with my fellow workers.

Agile is just a process people go thru where they disocver that they work with a bunch of clueless fucking idiots.