|
:cough: Scope Creep :cough:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
|
|
|
|
|
PIEBALDconsult wrote: Targeting a "general case" can be a slippery slope. It's not always a good thing.
* If it's a one-off and you won't have to maintain it and it'll "just work", then just get 'r dun.
* But, if you will have to maintain it in the future and the customer will want changes and you'll be endlessly touching the code? Then you better get the general case right.
It's a freakin' paradox!! 
|
|
|
|
|
PIEBALDconsult wrote: Targeting a "general case" can be a slippery slope. It's not always a good thing.
Besides, agile principles says that you should never, ever, make any sort of preparations for future extensions.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: agile principles says that you should never, ever, make any sort of preparations for future extensions.
Which one[^]?
Oh, you probably mean Scrum, right? 
I only believe in the original Principles, not all the add-ons that were created to allow authors to make $$$. 
12 Agile Principles
1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
|
|
|
|
|
raddevus wrote: Which one[^]?
In theory, there is no difference between theory and practice. In practice, there is.
A major reason why I asked to be moved to another project in my last job was that the project leader at several occasions made his corrections to my design, 'we do not have the resources to do that now!'. E.g. we were making a monitor, a minimal OS, for embedded systems, and in my proposal the request code was transferred in a register. The chip had an alternative software interrupt with an 8 bit request code embedded in the instruction. We 'didn't have the resources' to be prepared for more than 256 requests. So the design was changed to use the limited instruction. Less than a year later, the code range was exceeded, and software interrupts had do be rewritten to handle more request codes.
I had a couple other very similar issues where I had suggested solutions that allowed for extensions, that were rejected because 'We will cover the needs we have today, and that is it!' - and a year later, the simplified solution from the first round was replaced with my original proposal (or something very similar).
The project leader's rejection of more future oriented designs was fully supported by the majority of the development team. Avoid unnecessary complexity! --- As if transferring the request code in a register instead of in the instruction would lead to 'increased complexity'.
This is how I have experienced 'agile' software development in practice carried to its extremes. Thinking just a little bit ahead was like swearing in church; everyone who know anything about agility would try to silence you.
If you want to attach it to a single one of the principles, it would be 10. Simplicity--the art of maximizing the amount of work not done--is essential. Agile people, as I have met them, tend to live by the first part of Albert Einstein's pronouncement: Make it as simple as possible, fiercely fighting the second part, but no simpler.
I think this development group was at the extreme end. Yet I see a lot of the same in other environments. It was prevalent in internet protocols for the first 30 years or so - I wasn't the one pointing out that a lot of the protocols was missing a 'T': SMTP should be named 'TOO Simple Mail Transfer Protocol', SNMP should be 'TOO Simple Network Management Protocol', and so on. (I think SNMP was where I heard about the missing 'T' for the first time, and it immediately rang a bell with me.)
Theoretical agile principles are great for quoting at big celebrations. For practical work: Look at what people who claim to be agile are doing, not what they are quoting.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Great story.
My take-away is that "Good principles are always corrupted by bad people."
In your case, the Boss who has veto power but questionable knowledge nixes a perfectly good feature.
Boss has mentioned "Agile" somewhere along the line, so you attach the idea to this error-Boss.
Every Principle ever considered has exceptions and vast numbers of people who say the principle is a thing that it is not. So it goes.
It's why, in IT, I've learned that my motto is:
"Blithely I roll on." (see definitions 2 & 3 below)
wornik dictionary: blithely
adverb
1. In a blithe manner.
2. Without care, concern, or consideration.
3. In a joyful, carefree manner.
|
|
|
|
|
When I see the term "agile" I insert adaptive. Over the years of software dev. I learned that bottom-up and top-down usually occurs together, in tandem so to speak. One needs a big picture but one must also understand getting there from the bricks.
It's natural and wise to plan ahead, but not to an extreme. As the sign says "the future is tomorrow".
Also, from time to time, play the user as best as one can.
They are part of the target.
Don't know what this has to do with Spherical Cows,
but dogs run in circles because it is too hard to run in squares.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
trønderen wrote: says that you should never, ever, make any sort of preparations for future extensions.
I kind of like that one.
Because the vast majority of time the developer is coding for something that might happen 10 years from now.
Versus the much smaller and more reasonable case where they have seen a future Epic already broken down that adds an additional case. Of course the correct path in that case is to modify the current Story/Epic to insure it accounts for the future case.
|
|
|
|
|
Exactly… think of all of the software that was obsolete before Y2K so it never needed the updates!
|
|
|
|
|
Software being obsolete is no reason for not continuing to use it. I run a lot of obsolete software 
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Think of all of the software that will be obsolete after the year 9999.
No time like the present to start coding for that.
|
|
|
|
|
not our problem… Just wait a few hundred years for Mars Central Time Zone still with daylight saving time!
I hate time zones/DST and the fact that US legislators like to change them too often.
|
|
|
|
|
Myself the offset by 0:45 always annoyed me.
|
|
|
|
|
After solving a few specific problems in animation, I came to the "general conclusion" that the only things one needs to accomplish the full range of motion for a "shape", is x and y displacement and rotation (in 2D). A general solution has emerged that now drives all the others; "saving" time and mental energy.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Is the opposite of a Spherical Cow a Cubecumber?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
I know a company in India which is moving chips from general to particular.
They are designing chips for very specific purposes, almost with that particular instruction set (plus a small delta, maybe). They aim to lower memory and power consumption ... and more importantly, cost.
modified 13-Feb-24 22:07pm.
|
|
|
|
|
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference?
I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway....
So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so.
Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc.
Just like SVN.
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me.
Appreciate your thoughts.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
In the past year or so, at work, we moved to Git from SVN for all of our work.
Is it better?
I can't see anything that it does better than SVN.
Is it worse?
I can't see anything that it does worse than SVN.
Why use it?
Github has some nice features, although I will admit that I actually found it easier to navigate the commit history through TortoiseSVN, but I think that's partly a learning process for me and the Github UI is very poorly designed in places.
So if you like SVN stick with it, but it's always useful to have some experience of something like Git so that you can understand what other people are talking about when they mention "pull requests" etc.(another poorly named feature in Git)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I'm just trying to understand the FUD pushing git.
Where does your source code live?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
The source code lives on remote servers and locally - we have local repositories we work from and we then push to, pull from, fetch from, merge to the Git remote server repositories.
We clone from the remote repositories to local repositories and work on the local repositories.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
see my last comment - I think I see the big difference between GIT and SVN. GIT allows *all* work locally and then will put it back together on the backend, where that might be.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
When we were using SVN, I still have it on my local machine, we could do all the work locally too.
Perhaps an advantage of Git, which I missed is the concept of the PR (Pull Request).
With SVN we were able to commit to trunk without any sort of approval.
So I could get changes through to production without anyone else seeing the changes.
With Git nothing get's merged into Main unless it has been code reviewed and the PR has been approved.
This is a really useful safety net meaning at least one other person has looked at our changes before they are allowed to be merged into Main/Trunk.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
With Git you don't just have all the code on your local machine, you also have (or can have) all the branches, versions and tags on the local machine. That way you can compare or even revert code with any prior version without connecting a centralized server. Now when you want to share your changes, you can connect and push to say GitHub and pull to get changes from other users.
Branching in Git is also more lightweight since it isn't a full copy of the code base.
BTW, while PRs are useful and desirable when working with other developers, they are a feature of online git services like Github and Gitlab not Git itself. Depending on your settings/configuration, you CAN push changes to main (trunk) without anybody seeing it first.
|
|
|
|
|
SourceTree (if it's still around) had a pretty nice and buttony UI.
Web Git is maybe also a bit different than Azure DevOps on-prem Git. Not sure. But ADO traversal of history (or VS) works pretty decent depending on what you're after. May need a VS extension, I can't recall if it's built-in or not.
|
|
|
|
|
For me, one of the bigger advantages is, because I have copies of the repository locally, it makes it easier for me to undo history and rebuild. Suppose, for instance, that I added in changes to a configuration file that I didn't want to. With git, it's easy for me to undo that item. This may not seem like a big deal, but it really is. What this gives me is the ability to remove that item, and rebuild an application from any commit after that point; and the configuration entry will be gone.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
