Do it. Try it. Fix it.

Question

Do it. Try it. Fix it.

Viewing 14 posts - 16 through 28 (of 28 total)

You must be logged in to reply to this topic. Login to reply

f.clems SSC Rookie Points: 26 More actions · Answer 1

It may all come done to the interpretation, but this cycle seems perfectly relevant.

Do it: get the first draft implementation. I'm to often locked in meeting on how should it be done without any material/code to be evaluated. So do it.

Try it: let's run it and test it. How does it behave, did I break something. Evaluate it, communicate and get feedback. In the process let's learn.

Fix it: the test did not past, I broke something. Let's refine it and cycle.

No need to fix it any more. Ok, it can leave the DEV and sails to PROD.

This reply was modified 3 years, 2 months ago by f.clems. Reason: Clarify I'm breaking things in DEV

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 2

f.clems wrote:

It may all come done to the interpretation, but this cycle seems perfectly relevant.
Do it: get the first draft implementation. I'm to often locked in meeting on how should it be done without any material/code to be evaluated. So do it.
Try it: let's run it and test it. How does it behave, did I break something. Evaluate it, communicate and get feedback. In the process let's learn.
Fix it: the test did not past, I broke something. Let's refine it and cycle.
No need to fix it any more. Ok, it can leave the DEV and sails to PROD.

Not quite the right steps. It should be...

Design it. You should at least start to determine if its actually an improvement that isn't going to piss off your customers here.
Do it
Try it.
Fix it. Loop back to 1 or 2 as necessary depending on the findings. Don't try to save bad work... it costs more than coming up with a better idea.
Determine if it actually is an improvement. The most important judges in this are are your customers! For example, have you removed or degrading any functionality that they really want, need, or like? If so, it's NOT an improvement. Have the nads to go back to the drawing board (all the way back to the planning phase BEFORE step 1)
when such a non-improvement is judged BY THE CUSTOMERS and use some common sense. An example of this is the ol' "Ribbon Bar". Why did its implementation require nearly twice the number of clicks to get to the exact same menus as before?

Change can be really good but people have to stop thinking that changes of already good/great things is necessary. And for goodness sake, stop removing/degrading functionality or making the user interface or maintenance of the back end more difficult. It just doesn't need to be that way.

And if you have new functionality to add, make sure that its well designed and complete. MS was downright stupid in the design of things like the String_Split() function and the severely performance challenged FORMAT() function and the loss of a huge amount of functionality in the newer temporal data types just to a few of the dozens of disappointments they've come out with all while never getting to things like a built in, high performance, useful numeric sequence function for more than a decade.

The industry needs to change to doing it right the first time and "right" also means to stop breaking stuff. We need to get out of the cycle that Sergiy previously identified in this thread because it costs everyone a huge amount of time, effort, and money to "get used to" the crap changes that have been coming out in the last decade.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

f.clems SSC Rookie Points: 26 More actions · Answer 3

Ok, that is not the full development cycle. And I associated fix it with improve it. I spend my time in a system created out of an ORM reproducing inheritance in the database. This is over for the good design, o-v-e-r. But the hope remains. So may it be fixed/improved. We make steps every day in what we (database developers) consider relevant for the data intgrity/security.

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 4

To be sure, my rant on this subject isn't directed towards anyone in particular, especially the poor ol' developers (I used to be a front-end developer a long, long time ago and still develop for the database even though my job title is "DBA") on both sides that are required to write only the code they've been directed to write according to a usually too-short schedule. My rant is about the industry in general and the ridiculous end results that they advertise as "improvements".

It IS, however, a part of the Development cycle... probably one of the most important parts. While Developers of all walks aren't the main problem, they still are a part of the problem. It's just that they (we, actually) stand no chance of getting better if they keep getting told things like "Just follow the requirements... you're not designer" every time they try to make a suggestion.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

f.clems SSC Rookie Points: 26 More actions · Answer 5

Jeff Moden wrote:

, they still are a part of the problem. It's just that they (we, actually) stand no chance of getting better if they keep getting told things like "Just follow the requirements... you're not designer" every time they try to make a suggestion.

Do we have a list of tricks to fight back such management statement? (Appart from moving to management or quitting the position)... manipulate your manager 101?

Sergiy SSC Guru Points: 110206 More actions · Answer 6

Jeff, what you describe is the essence of Agile Development, as it's done nowadays.

to fix the quality of software product the industry has to outlaw terms "agile", "sprint", etc.

You can never win a marathon if you run it as a set of sprints.

Well, you can, if you convince all the others do the same...

_____________
Code for TallyGenerator

Sergiy SSC Guru Points: 110206 More actions · Answer 7

F.clems, if you need to use tricks and manipulation to bypass the system in order to get a good result, then the system is broken, don't you think?

_____________
Code for TallyGenerator

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 8

I've had many managers in the past 20 years. Some were good, some not so good, and some were terrible. The not-so-good ones can sometimes be "trained" through demonstration of what-could-be. That takes some time, effort, communication, and cooperation between you and the managers. The ones that are terrible can sometimes be "trained" to understand but usually not. There is NO magic formula. There has to be the right kind of communication and incentive from both parties. Both have to win or it's just not going to work and "manipulation" is the worst word in the world for this type of thing.

I've also been a Director of IT and a Manager of Development and a CTO. I've slowly worked my way "down" to being "just" a DBA with (thankfully) no direct reports. If "management" is your thing, go for it but I hated it. And even after "training" both on the part of your manager and yourself, you shouldn't expect everything to be a bed of roses. It's just not possible for your goals to always match the goals of the manager or vice versa.

Also consider that it's not brown-nosing to help your manager look good. It's actually your primary responsibility because, like it or not, that's what you were truly hired for. If you don't want to do that for a particular manager and communications suck, it's time to move on.

By the same token, remember that the only difference between a brown-noser and a s4ithead is depth perception. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 9

Sergiy wrote:

Jeff, what you describe is the essence of Agile Development, as it's done nowadays.
to fix the quality of software product the industry has to outlaw terms "agile", "sprint", etc.
You can never win a marathon if you run it as a set of sprints.
Well, you can, if you convince all the others do the same...

Ah, nope. It can certainly be applied to agile, sprints, and what people mistakenly call "DevOps" but that's not how I meant it nor do I subscribe to those things. As you say, you can't win a marathon in sprints (reminds me of the tortoise and the hare parable). My goal is to suggest that you have a sound design, a good reason for a change, and it's a good change or it should be abandoned without remorse (but DO learn the lessons provided). The old Turkish saying is, "No matter how far you've gone down the wrong road, turn back, turn back".

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 10

Sergiy wrote:

F.clems, if you need to use tricks and manipulation to bypass the system in order to get a good result, then the system is broken, don't you think?

Totally agreed. And you should never use "tricks and manipulation" to get a good result. If you can fix the system, that's good. If you can't, then don't waste your time. Also know the difference between those two things. But, whichever way it ends up, I totally agree... neither tricks nor manipulation should ever be used. Neither is worthwhile and I wouldn't hire someone that I knew that had resorted to such things unless I happen to be in the business of hiring professional liars (and I'll never be in such a business).

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

f.clems SSC Rookie Points: 26 More actions · Answer 11

Sergiy wrote:

F.clems, if you need to use tricks and manipulation to bypass the system in order to get a good result, then the system is broken, don't you think?

I tend to try to fix broken systems. And sometimesthey do break me. But kind of stubborn here. Thinking of it, I may give a more thoughtful try at https://www.red-gate.com/simple-talk/opinion/opinion-pieces/on-training-your-it-manager/

f.clems SSC Rookie Points: 26 More actions · Answer 12

Ok tricks and manipulation were surely not appropriate. Pfiou... clear commutation really is an art.

Thanks for the advice. Sincerely. Food for thought at an appropriate time here.

Sergiy SSC Guru Points: 110206 More actions · Answer 13

Jeff Moden wrote:

I've had many managers in the past 20 years. Some were good, some not so good, and some were terrible. The not-so-good ones can sometimes be "trained" through demonstration of what-could-be. That takes some time, effort, communication, and cooperation between you and the managers. The ones that are terrible can sometimes be "trained" to understand but usually not. There is NO magic formula. There has to be the right kind of communication and incentive from both parties. Both have to win or it's just not going to work and "manipulation" is the worst word in the world for this type of thing.
I've also been a Director of IT and a Manager of Development and a CTO. I've slowly worked my way "down" to being "just" a DBA with (thankfully) no direct reports. If "management" is your thing, go for it but I hated it. And even after "training" both on the part of your manager and yourself, you shouldn't expect everything to be a bed of roses. It's just not possible for your goals to always match the goals of the manager or vice versa.
Also consider that it's not brown-nosing to help your manager look good. It's actually your primary responsibility because, like it or not, that's what you were truly hired for. If you don't want to do that for a particular manager and communications suck, it's time to move on.
By the same token, remember that the only difference between a brown-noser and a s4ithead is depth perception. 😉

The issue here - my "demonstration of what-could-be" won't buy anyone's heart.

As Jake Sully said - "There's nothing that we have that they want".

Managers want 2 weeks deployment cycle. If they miss a scheduled deployment - it's their fault, therefore it's not acceptable.

If they release a code which is not ready, did not pass the test or was not properly tested - it's DEV's fault, and it's not a biggie, as the DEVs can fix the issues in 2 successive hot fix releases.

And if the customer starts complaining - well, you've been complaining about the "features" of this new forum for how long? So what?

"get used to it" - was not it what you've got back?

Customer satisfaction is not anywhere near of the priorities for Agile developers. And improved quality of the product which could probably compromise regularity of releases is exactly what they don't want.

_____________
Code for TallyGenerator

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 14

Yep... that's the way it is... not the way it should be. That's exactly what I'm talking about. That junk methodology needs to be fixed.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)