Start with one thing at a time. Do that one thing excellently until it becomes part of your soul, and you could never imagine not doing it. Then move onto the next thing.
HN user
postfacto
Someone on the Internet summed it up well
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Yes, Agile does produce more buggy, less stable software. There is heavy bias towards doing only simplistic, user-visible things that fit in the span of two weeks. So all the foundational stuff you need to put in at the start of the project to let you support features while reliably turning direction on a dime? Can’t put it in there.
I’ve seen many agile shops fail to ever get CI/CD working because the effort just couldn’t find a place and a schedule on the backlog.
Dovetails nicely with the whole Right To Repair shit that farmers are currently having to go through with John Deere.
they were demanding something in a timeframe that I couldn't deliver it without ensuring that there wouldn't be any unintended side effects - and then blaming me for the side effects when they came up.
Far too few developers understand: just because the people writing the checks ask you to do it and you implemented it exact as they ordered you to doesn't mean the people writing the checks will take responsibility for the resulting bad situations that can lead to them not writing you checks anymore. If anything, you'll be used as a scapegoat to prevent them from not getting any more checks written.
Example #4
A CTO of an American company, to get a bonus of $7 million, lays off a ton-load of the company’s CRM people who knew how 20 years of architecture duct tape that ran the company was strung together.
CTO then proceeds to hire a cheap, offshoring body shop to design the company’s new website, which talks to the CRM. However, there’s no more CRM people at the American company because they’ve all gotten laid off and the offshore web contractors also now have to become customized CRM experts, which is insane scope creep.
The outsourcing company can’t deliver and litigation is sought, while the US company takes zero responsibility for the fact that all the CRM people were let go and there’s no chance in hell that web developers at the outsourcing can ever learn the highly customized domain-specific logic that fast that extensively. Meanwhile, CTO gets fired and a severance of $1 million for all the extreme damage he did to the company.
And that’s Hertz vs Accenture, or at least how I heard it to be.Deming’s First Theorem:
“Nobody gives a hoot about profit”.
Apparently you’re in good company
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Truest comment I’ve read so far.
If simplicity is always the right solution, then why do so many programming languages have dedicated parsing libraries for .csv, which has to be the world’s most simplest data format ever?
Scrum allows for granular micro-tracking of developers at a daily level while sanctifying the ideas of developers as interchangeable cogs and that leaderships should be able to move the goalposts at the last minute.
What’s for an enterprise exec not to love?
One possible hypothesis is that spacetime itself is being warped in such a way that no significant forces caused by interaction with the atmosphere are being generated.
Kinda like how because you ride an escalator people no one ever hears you climbing stairs.
A truly worthy book of Software Engineer Dark Arts that’s come in handy multiple times.
The Career Programmer: Guerilla Tactics for an Imperfect World (Expert's Voice) https://www.amazon.com/dp/1590596242/ref=cm_sw_r_cp_api_glt_...
Agile destroys any software project it’s allowed to touch by sabotaging development of early architecture through the “it must fit into two weeks” mandate and other assorted short-termist practices.
But the F-35 was already a shitshow, because the aircraft itself was designed using agile, though the Pentagon called it “concurrency” instead of calling it “agile”. Concurrency (agile) was also used for the Littoral Combat Ship (LCS), which produced a similarly disasterous, unreliable four-assed monkey that neither the Chinese nor the Russians would ever take seriously.
Why the downvotes? This comment’s dead accurate.
For those transitioning from programming to woodworking, if you don’t understand how to use your table saw, you’re not supposed to design and build your own table saw because you think you can build a better one.
I thought Transformers were “Robots in disguise”.
I’ve found the two codebases approach, one for iOS and one for Android, is simpler and cheaper because native development tools are just so better.
So in 2003, before the iPhone came out, I was a mac developer doing Cocoa/Objective-C development.
I then tried to learn Symbian and I found the IDE hard to setup, the API was hard to learn, and I believe it only ran on windows.
At the time I thought to myself “the NeXT/Cocoa API and utilities are so awesome, so easy, so mature that if Apple ever makes it possible to write mobile apps with them, they are totally going to absolutely destroy everyone else in the mobile development marketplace. Especially Symbian.”
Anything is capable of not sucking if you go out of your way to spend several man-decades optimizing it.
Fezzes are cool.
Agile In Their Own Words
https://github.com/rayfrankenstein/AITOW/blob/master/README....
This is brilliant!
Perhaps agile doesn’t actually work (despite the hype) and your team having this quandry is actually your team starting to be awakened to the truth of why agile tends to cripple any project it touches.
Dump agile, write the backend first, in a thick juicy horizontal slice, create a decent json schema document for it that you show to important people at the mandatory demo, and then hand the schema document to the front-end person with the understand you may have iterate on your API a bit as you incorporate their feedback.
Narcissists are very charming initially and very good at hiding it. Some tells:
- Very attuned to their own fashion attire. Very well/trendy dressed.
- Use the words/phrases “value”, “add value”
- Brag about themselves a lot. Talk about very lofty standards about very minor details.
^^ This.
Also, your real job is making your manager look good to his manager, not actually the nominal job of writing reliable, stable, flexible code that you signed up for in your employment agreement.
Many businesses go with Xamarin because some guy in a management mandates it because he feels it will be a silver bullet that will let them get around having to hire skilled native mobile developers.
The reality is that to do Xamarin well you’ll have to wander outside out Xamarin Forms, and to do that well not only do you need native mobile developers but you need far higher caliber native mobile devs who are able to mentally translate swift/objc and android calls into their C# equivalent, and who have an idea of what’s going on the os when there’s a crash at a level lower than the .NET runtime caused by a native part that’s not apparent in the crappy Xamarin stack trace.
Xamarin really only makes sense if your company has a mountain of existing complicated .NET code with priceless business logic that you absolutely have to reuse.
That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color.
Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.
absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product.
I once had a manager who, on the subject of upper management wanting to ship the prototype, would say “the difference between dev and prod is one letter.”
I’ve noticed this, too. For some reason a junior developer on my team 2 years our of school was made into scrum master, and if we so much as sneeze there’s no JIRA ticket for it he starts whining.
It’s been my experience that most programmers who have worked on many different projects across many different employers for many years can intuit whether something will be needed with a very high degree of accuracy.