Profit, Doors, Science, Windows

[swatts]

What-ho Lovelies,

This is a phrase lifted from a reference in my friends dissertation.

"When profit comes in the door, does science go out the window?"

Forde,  Psychometric Testing – Critical perspectives

It struck a cord and this was backed up by a conversation I had with a very high-placed nutritionist. To paraphrase my conversation in one cumbersome question "Do you find that the scientific/practical nutrition world gets taken over snake-oil sellers offering packaged quick-fixes" her answer was an emphatic and angry "YES!". And this has always been my issue with some aspects of computer science and process.

Agile

"We are uncovering better ways of developing
software by doing it and helping others do it."

When the agile manifesto was first published it was presented by experienced software engineers. It was great for delivering large projects, where customers were not seeing their software for years on end. It was a huge change for those projects.

Over the years the whole thing has been packaged and productionised so that there are practitioners who have never written a line of code. In short it has been taken over by project managers and often poorly trained "consultants".

What we've ended up with is not "Individuals and interactions over processes and tools"........

but this!

I honestly don't know how any software engineer can look at this and not despair at how far from the Manifesto for Agile Software Development we have strayed.

I have nothing prepared, but I have a suspicion that I could apply a similar argument against some software design dogma. Nobody seems to ask who is giving out the information? What is their experience? How does their experience help with my problem?

The other thing to realise is that most current computer science comes from people without large projects under their belts. We're being lectured on programming by people who don't do a lot of programming. I did a brief search around on some of the famous names telling us about software design and there was a noticeable absence of software on their bios.

In this unscientific environment the only defence is to be open, but sceptical, try something and see if it gives improvement. You are the control in this experiment.

Another observation is that simple is very hard to package and sell, complex is much more profitable. IMO this skews everything to the complex. Whenever I see something complex I start looking for someone who is profiting from it.

Profit is not a bad thing, it's the skewing to the complex and sowing fear that I object to.

Computer Science has a great deal of value, but we should understand the limitations and differences between the projects and processes used compared to our problem domain before slavishly following advice.

Another consequence is the wrappering and layering of complexity. By this I mean the solution to a complex solution is not to simplify by removal, it's to simplify by wrapper. This leads to bloat and bloat is the thing that will kill your project.

If you like my writings, you may enjoy my speakings.

I can be found on the newly released GDevCon#2 videos, I highly recommend checking all of the vids out there is some great content here!

Check out our YouTube channel.

https://www.youtube.com/channel/UCJ0jhJNGk9kjc12npjy6b4g

Lots of Love

[Taggart]

Dead on Steve!

One of the tenants of Agile is: 

The best architectures, requirements, and designs
emerge from self-organizing teams.

I interpret this as let the team determine what is appropriate for their situation. and yet you have Scrum and SAFE with this proscribed program that probably worked in one particular situation and then trying to impose it in a top-down manner. It just doesn't seem congruent to me.

By the way here is anothre mind blowing graphic for you 

Now reading between the lines of the Agile manifesto it seems one of the tenants is to be close to your customer, ie constant communication and constantly delivering value.  This diagram explains the Essential SAFE (There are several more complicated versions). So according to them in order to be agile, you have to be doing all this stuff.  You think it might revolve around the customer. Don't surprised if you can't find the customer in all that mess. He actually does appear somewhere in the upper right corner. But they use a smaller font and it's not bolded like the other titles.  Apparently all the titles and activity are more important than the customer. Really makes me want to go hire someone who adheres to this (he says sarcastically)

[drjdpowell]

That's what I'm missing, an "Architectural Runway"!

[Taggart]

It's like a fashion show for your architecture!

[Taggart]

Apparently you need some model train tracks too for your "Agile Release Train".  I wonder if it's like the slow American style or like the bullet trains they have in Japan?

[Jacobson-ni]

In addition to looking at the experience of someone giving advice, I would also recommend looking at what type of experience they have. Someone doing embedded systems development for a defense company might have very different thoughts about software than someone doing app development for a startup. They could both be labeled as software engineers but they work in pretty different worlds which I think people can easily forget. Not saying sharing information between them would be useless but you have to be open to the fact that their ideas could be perfectly valid and yet not helpful to you.

[swatts]

I'm moving much more towards an individualist, strengths based approach to software management and what you said there rings very true.

I've put in an abstract for NIWeek 2020 that will allow me to research this a bit more.

[Taggart]

Well said Matt!

As with most things in life the answer is "It depends on the situation." I think in general there are some principles of Software Engineering that are mostly universal, however how you implement them and which ones get more emphasis very much depends on the problem you are trying to solve.