|
Out of topic, but what's with the #realJSOP ? Did I miss something ?
|
|
|
|
|
I wanted to change my display name to JSOP, but someone is already using it, so I changed to #realJSOP.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Ah, that's bad luck. Have you tried bribing the hamsters  ?
|
|
|
|
|
nah - I haven't even decided if I like it. I can't find my posts as easily now.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I wish you much luck. Having worked in a similar environment I understand the (ack! I going to use corporate speak here) headwinds you are up against.
And Lopatir was being a jerk in this instance.
|
|
|
|
|
I talked about my project with one of the other developers this morning, and he seems genuinely interested, and suggested that I do a demo when I'm ready. I think they'll be generally receptive to my nefarious plan, because much of the tedious stuff is already handled, and a lot of the trail-blazing has been done regarding the newer technology stack.
I'm optimistic.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Reading this short section of how the Agile process arose is interesting to see what was really behind the idea. From (Unlocking Agility: An Insider's Guide to Agile Enterprise Transformation (Addison-Wesley Signature Series (Cohn)): Jorgen Hesselberg: 9780134542843: Amazon.com: Books[^])
This book provides an amazing history of software development and how we’ve gotten to where we are. Definitely worth the read.
Quote: Yet in writing the Manifesto, these software professionals realized that they had created something deeper and more profound.
Jim Highsmith, one of the signatories, noted:
“I believe Agile Methodologists are really about “mushy” stuff about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset.”20
James Grenning, another signatory of the Manifesto, agrees. “The Manifesto was written in a time when Process was clearly valued more than People. Since the signatories were people who were writing code every day, we could see the harm that this thinking did to our work and to the products we created. More than anything else, the Agile Manifesto is about making the world safe for programmers.”21
The signatories were primarily interested in finding ways to create environments for writing better software while the profession found itself in a crisis.
|
|
|
|
|
Of course all this stuff just proves that there are no fixed solutions to our problems. Agile is almost a dirty word now to a lot of people because it's all about process (or all about the process of ignoring process at the expense of quality I guess?)
Ultimately, very non-trivial software is always going to be very complex, and no methodology or language or tool is going to substantially untie that knot, certainly no fixed set of them. Every situation and every developer and every problem domain are different, and one set of tools and techniques isn't always going to work. But, making it up as you go along every time also isn't likely to work most of the time.
It would take one person, with a lot of technical knowledge, a LOT people skills, the power to make it so, and to be left alone to make it happen, to pull that off, and how likely is that to happen in a big company? And how many of those people are there? Not many.
And of course even if you did do that, you'd have to accept the fact that sometimes it's going to fail. That's sort of the trade off. You can go Dilbert mode and probably get something that will not fail because it's over-processed the entire time and as much time is spent talking as doing. Or you can spend a lot of time doing and letting the people on the ground do what they believe is right, but you end up with some brilliant successes and some horrible failures. And no one wants to risk being one of the horrible failures (or more to the point, paying for one of the horrible failures.)
So there's not really a solution ultimately, other than hire the best people you can, or the best TEAM you can, give them a lot of leeway but somehow manage to make sure they don't go off the tracks without watching them so hard that you interfere with their creating something potentially great.
Can anyone think of any truly amazing or original or game changing software that wasn't created by a smallish team of people who were mostly left alone (or ignored because they were in a company so big no one upstairs know what they were doing?) But, OTOH, how many of those same scenarios failed miserably and we just never heard about them, because they never went anywhere and wasted a bunch of money?
Wow, that was such a positive post on my part. But I just feel like I'm realist. There's no solution. Human nature and the inherent complexity of the problem cannot be gotten around with any sort of magic wand. You can only muddle through it every time and hope for the best. But, the vast bulk of the time it will be a 'one solution really fits none, but at least we probably won't all be fired and run out of the business', process oriented scenario of some sort, right?
Explorans limites defectum
modified 17-Mar-19 19:16pm.
|
|
|
|
|
Everything you are talking about is why this book is so fantastic.
The author takes the history of software development back to the publication of the seminal management theory book from 1911 (Principles of Scientific Management by Frederick Winslow Taylor). His point is that companies are still managing people and processes by that guide written over 100 years ago.
Quote: It was not lost on the people doing the work (the programmers) that the way things were going was not sustainable. Throughout the 1990s, professionals across the software industry would meet periodically and share ideas. What do some of these emerging ways of thinking have in common? What are ways that we can improve the way software is written? People recognized that things needed to change, but the ideas had yet to coalesce in a meaningful way.
Quote: As a result, top-down, fixed strategies—however well executed—no longer predictably yield the results we expect.
From the perspective of the incumbent accustomed to doing business in a more predictable world, this type of business environment may seem chaotic. Only by adjusting and learning better, faster, and more economically than their peers can companies gain an “agile advantage.”
To start embracing a new way of operating, it is necessary to think beyond the simplifications useful in a more predictable context defined by early thinkers such as Frederick Taylor. As the world has changed to become more complex, the way we approach business strategy needs to reflect a more adaptive view of the world.
|
|
|
|
|
From a consumer point of view.
I use DAW software. It's used to be 600+ bucks or less for current users with new releases once a year predictably in each fall. The features and fixes we all opined for all year on the user forum were either in the release notes or not. There was little or no access to the Indians within the company to try to lobby your pet stuff with. This was normal in the world.
Then they changed and announced features would be released when they were deemed ready and bugs fixed too which resulted in new toys for us roughly every month. Inexplicably, the updates are free to us now - we don't know why but we don't push it. 
btw it's Cakewalk by Bandlab
|
|
|
|
|
I may not have said it directly enough but I really like the things you said in your post.
Especially the following because I completely agree with you...
Dean Roddey wrote: Can anyone think of any truly amazing or original or game changing software that wasn't created by a smallish team of people who were mostly left alone (or ignored because they were in a company so big no one upstairs know what they were doing?)
Now as I've continued further into the book I came across this...
Quote: This takes us back to Professor Watts’s initial observation: what is it about cities that make them so robust and virtually indestructible, compared to companies? Dr. Watts theorized that the way cities are managed helps them embrace uncertainty in a way that allows them to benefit, rather than suffer, from unexpected events. By creating boundaries within which people can work together toward a common goal, the cities’ leaders can influence—rather than control—an outcome, while allowing for creativity, collaboration, and serendipity to naturally happen.
When companies want to get more innovative, we typically hear of chief innovation officers and special initiatives in which employees are directed to submit ideas and vote for interesting concepts. People are rewarded nominal prizes if their ideas are selected, and a nice article in the company newsletter is written. This sounds nice enough; the only problem is that it does not work. Internal innovation programs are notoriously ineffective. An MIT study found that 80% of innovation is a result of coincidence and chance. You simply can’t “force” innovation.
|
|
|
|
|
raddevus wrote: The signatories were primarily interested in finding ways to create environments for writing better software while the profession found itself in a crisis.
Define "crisis." Another word that has become cliche. I'd actually like to know what "a profession in crisis" looks like. 
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I'll send you a selfie...
Explorans limites defectum
|
|
|
|
|
I'm fairly sure this guy could tell you exactly what a crisis is ==> Refactoring the soul[^]
I think that situation is a lot of what those Agile signatories were talking about.
|
|
|
|
|
raddevus wrote: I'm fairly sure this guy could tell you exactly what a crisis is
Hey, I resemble that remarc. 
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
IMHO - two things.
1 - In my experience (in multiple companies), the implementation of agile has led to a bureaucratic layer of project managers and business analysts with no proficiency at software engineering nor the software development lifecycle. The end result are projects that take too long, lean towards mediocrity, and cause the customer (internal or external) to blame the developers, whose hands were tied by the aforementioned project managers and business analysts.
2 - I went back to the original Agile Manifesto, and this article explains how I see those principles could be applied effectively today, at least in my own country. https://www.linkedin.com/pulse/agile-principles-from-traditional-american-view-jeff-jones/[^]
I understand if others disagree, which is why the first four letters in this post are "IMHO".
|
|
|
|
|
MSBassSinger wrote: 1 - In my experience (in multiple companies), the implementation of agile has led to a bureaucratic layer of project managers and business analysts with no proficiency at software engineering nor the software development lifecycle. The end result are projects that take too long, lean towards mediocrity, and cause the customer (internal or external) to blame the developers, whose hands were tied by the aforementioned project managers and business analysts.
Yes, that sounds like most projects everywhere, most of the time.
That is because that the old "We manager-types will tell you how long things should take and the functionality that should be in there, even though we have no idea about either one and have not even attempted to gather data about either one."
That is the old-school management theory that the author of Unlocking Enterprise Agility is attempting to open everyone's eyes to. It is based on principles from 1911 with a study of how people are like machines so we should just determine how many movements they should make to build a product. Then we can just set the schedule and have the minions crank out the widgets.
But, of course, if you call the thing Agile but all the principles still follow the old-school pattern then you do not have Agile.
2- I'll read the article. It looks quite interesting.
|
|
|
|
|
Thanks. I agree. I am a bit dumbfounded as to how thinking professionals see software development as essentially assembly line workers (developers and testers) on a predictable assembly line, instead of professional engineers (not PE, but generically) creating value from thin air.
|
|
|
|
|
Yeh, I mean, I've said it time and time again... how many of us, when starting a new project, are doing something that we have done just like that before, with the same tools, the same techniques, and the same constraints, and of course with the same team (known quantities)? It's probably never happened to any of us even once.
Every significant undertaking is new. You can't predict results without repeatable conditions, and no one even WANTS repeatable conditions for the most part because that would mean not taking advantage of lots of new things that will have become available within the lifespan of the previous project (if it was of any size.)
It's like most space projects. NASA and ESO have some of the best engineers in the world, but they almost never bring in anything under budget and on time, and all too often make massive blunders, because they are never doing the same thing twice. No matter how much process analysis experience you have, if you haven't done it almost exactly like that before, then you are to one extent or another throwing darts at a board.
Explorans limites defectum
|
|
|
|
|
I agree with you MSBassSinger. I worked for an company back in the late 80s that hired its software manager from a well-known accounting firm. He believed that software production is the same as an assembly line. People like him are extremely lacking information.
For example, workers on an assembly line have blueprints (or exact instructions) on how to build the product, which part goes where, how to put the part into the product, and how to inspect and test the product. Those plans even include an inventory of parts needed and the company stocks the needed parts.
Where are those instructions for the software developers? Although, the parts are endless, what parts will I need and how many? Should I use an array or linked list for an operation? A simple sort or a quick sort? Which would be best if the software changes at a later date? Is the performance of my new algorithm fast enough or do I need to add something more to it?
Even the hardware engineers create a breadboard to test their ideas when creating a new product. Do I use a 40 ohm or 80-ohm resister? There are no instructions of how to build it before it is conceived.
Does someone think that a customer’s or marketing’s request and requirements (even if detailed) is enough instructions to build a product? Can the customer or marketing give us the detailed specifications about the internal processes. If we refer back to the old days of software engineering (looking back to IBM in the 60s and 70s), there were processes in place to conceive of the breakdown, product boundaries, design, testing, implementation, deployment, and maintenance.
Any manager who doesn’t have software experience should be handled with care. Time needs to be taken to educate that manager, so he knows what he is working with.
|
|
|
|
|
|
That’s exactly how the process goes. 
|
|
|
|
|
|
These learned gentlemen would be contemporaries of Pink Floyd? That sort of education?
|
|
|
|
|
FYI, "Learned gentlemen" are barristers or solicitors (lawyers to you USians). These are Peers of The Realm.
Lord Ashton of Hyde was born in 1958, Lord Geddes was born in 1937, and Pink Floyd was founded in 1965. This makes Pink Floyd too early for one, and too late for the other.
Until comprehensive education was largely replaced in the UK with Comprehensive education, it was possible to get an education well-grounded both in Classics and in Science. The idea of getting a comprehensive education has sadly been relegated to the dustpan of History.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
