|
Lopatir wrote: Well that is precicely was what I was asking you. Rant? Selling an idea? Asking for help?
None of the above. Like I said, I was just talking about what I was up to this weekend, and felt like the background info was necessary to explain what I did and why I did it.
Lopatir wrote: Your presentation skills suck.
It's posted in a discussion forum, it's not a f*ckin white paper.
Lopatir wrote: And what that means: Nobody's going to buy into it. ..as to a video: you'll only embarrass yourself.
We work in a vault (not quite a SCIF, but access and content are controlled), and we're not permitted to bring code in from the outside without jumping through a lot of security hoops. To avoid the hoops, I'm going to use YouTube to create a (private) demo video that we can access from inside the vault. If after seeing the video, there is interest to actually see the code, I can schedule an external conference room and hook my laptop up to the big-ass display system. Getting time in the external conference room is a substantial hassle and the wait time for available slots varies from one to three weeks. Before I ask my manager to go through the scheduling process, I want to see if there's any general interest. THAT is why I'm making a demo video. Embarass myself? Probably not.
".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
|
|
|
|
|
#realJSOP wrote: To avoid the hoops, I'm going to use YouTube to create a (private) demo video that we can access from inside the vault.
Have you approached Troy McClure?
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
#realJSOP wrote: I think I'm almost ready to show off my baby to the other devs on the team.
Hopefully you work with people (and management) that doesn't see your initiative as competition, one upmanship, or in some similar negative light!
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
|
|
|
|
|
Jobs are easy to find. Like I said, I don't care, because now I have something in my portfolio that I can demonstrate to companies that claim to appreciate my unique brand of initiative in the face of ruin and doom.
".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 read it all.
At the risk of exposing my Cowboyishness, Y'all are a saint.
|
|
|
|
|
I need to run out and get a microphone so I can record my commanding voice with the demo video.
".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
|
|
|
|
|
Add a little reverb and maybe some pitch-shifting or subharmonics. Get a voice a real voice-of-god thing going.
Nah - that could be too intimidating. Never mind.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I'd be a bit careful with public demo videos, and the like. The people you're contracting to might (choose to) see it as a breach of copyright.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It's gonna be a private vodeo that only I can view (if youtube is to be believed). I plan on doing it in the conference room. Besides that, it can't be a copyright violation - it's taxpayer funded.
".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
|
|
|
|
|
First contract, huh?
|
|
|
|
|
Nope - been doing contract work on-and-off since 1980. If you saw our current code base, you'd be highly motivated to update it, too.
On the other hand, I'm re-learning MVC, and bending EF to support my nefarious plan (ALL of our database queries are performed via stored procedures).
Something I learned about ADO Data Entity Model - when you "import" stored procs, it generates a model based on the dataset returned by the store proc... unless you're returning a dataset from a temp table. For some reason, EF goes deaf, dumb, and blind in that instance, forcing you to manually create the model - OR rewrite the stored proc to not use a temp table so the model can be generated automagically.
".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
|
|
|
|
|
Yeah, it was me that told you that EF isn't really geared up for SPs, it supports them but it's really intended for generating dynamic SQL. Using SPs is generally considered legacy these days.
|
|
|
|
|
Yeah, but we deal with so.much.data (with hyper-convoluted business rules), and have so many concurrent users that it is not practical to not use stored procs.
".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
|
|
|
|
|
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
|
|
|
|
|