Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | TuneIn | RSS
It’s time for another episode as Joe wants to choke a developer, Michael scraps his new social networking platform, and Allen finally learns of dad jokes while we continuing the anti-patterns conversation.
Using your podcast player to read this? Find this episode’s full show notes at http://www.codingblocks.net/episode66.
Sponsors
- Linode – Use code “CODINGBLOCKS17” for $20 towards hosting (up to four months free!)
Survey says …
This episode we ask, having multiple monitors is great. But at they …
News
- Thank you for our latest reviews:
- iTunes: Laserath, ReallyOldCoder, thejungn
- Stitcher: frostblooded, joseluah, andre_macedo
- How do you pronounce kludge?
- Paul Spoon had the idea of pronouncing it as difficultly as possible
- Ambix on Episode 65 – TVP – poor performance? Use a temp table…also…terrible people
- Joe Recursion Joe on Ep 65 as well – great example of that magic pushbutton
- http://www.codingblocks.net/episode65
- Facebook Patent / Licensing Uproars?
- Allen finally built his Hackintosh and loves it.
- Wanna know his favorite part? Did you guess the CPU cooler?
- Is sql server utilizing alien technology? Pyramids, Who shot JFK, Long Island Medium?
- What’s your preferred title?
- Blind programmer listens to code at sonic the hedgehog speeds
- New mics, let us know what you think!
Project Management Anti-patterns
Cart before the horse
- Focusing too many resources on a stage of a project out of its sequence
Death march
- A project whose staff, while expecting it to fail, are compelled to continue, often with much overwork, by management which is in denial
- The project is destined to fail, hence it’s a death march
- These projects are the result of unrealistic or overly optismic expectations
- Scheduling
- Scope
- Both
- Coupled with a
- Lack of documentation
- Lack of training/expertise
- Hurts team morale/psyche
- Management often believes the problem can be corrected by:
- Everyone working longer hours
- Adding more people to the project
Ninety-ninety rule
- Tendency to underestimate the amount of time to complete a project when it is “nearly done”
- Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. – Douglas Hofstadter
- Similar: 99 Rule, 80/20 Rule, Hofstadter’s law, Pareto Principle
- Different definitions of “done”
- “Put a bow on it”
- How do you know when you’re falling into this trap? Have you made any estimations?
- How to prevent? https://stackoverflow.com/questions/1099637/how-does-one-deal-with-hofstadters-law (Yishai)
- Estimate in small chunks
- Work in small iterations
- Focus attention on what caused the deviation from the estimate to make the next estimate better.
- Don’t estimate
Overengineering
- Spending resources making a project more robust and complex than is needed
- Designing of a product to be more robust or complicated than is necessary for its application
- Overengineering can be desirable when safety or performance on a particular criterion is critical
- Wasteful in terms of value engineering
- In contradiction to the KISS principal and less is more
- Products are more complicated than necessary – Using DDD for CRUD is full on overengineering
- Can make user interfaces too complex for what the user’s needs really are
- Making something work for more users than necessary (must scale to the world)
Scope creep
- Adding new features to the project after the original requirements have been drafted and accepted at any point after the project begins
- Also known as:
- Requirement creep
- Function creep
- Kitchen sink syndrome
- Occurs when the scope:
- Is not defined
- Not documented
- Not controlled
- Similar but distinct from feature creep
- Can be a result of:
- Poor change control
- Lack of defining a project’s success metric … i.e. it’s objectives
- Weak project manager / executive sponsor
- Poor communication
- Lack of versatility
- Large, mega-projects often fall victim to scope creep
- Adds additional cost to the project
Smoke and mirrors
- Demonstrating unimplemented functions as if they were already implemented
- Every E3 demo ever
- Smoke and mirrors is an idiom for a deceptive, fraudulent or insubstantial explanation or description
- Think about the illusionists
- BTW David Copperfield made the Statue of Liberty disappear: http://gothamist.com/2016/05/04/david_copperfield_statue_of_liberty.php
- Volkswagen: $200k and 40 months… https://www.theregister.co.uk/2017/08/25/vw_engineer_gets_3yrs_for_emissionbusting_sw/
- How do you know…just kidding…you know!
- Is this an anti-pattern, or a way of life?
- Often times the prototype becomes the product
Brooks’ law
- Adding more resources to a project to increase velocity, when the project is already slowed down by coordination overhead.
- Adding more technical resources (people) late in a project does not increase productivity and reduce the timeline
- Ramp up time is real
- Takes time away from existing (productive) people on a team to help educate the newer people on the team
- Newer members may even slow things down further by introducing bugs because they don’t understand how all the pieces fit together
- Communication overhead is also real
- As you add more people to a project, the more people need to intercommunicate in order to stay in sync – this is a real problem that does not scale well
- Limited divisibility of tasks
- Compared to adding more people to cleaning a hotel room – at some point people just get in the way of each other
Resources We Like
Tip of the Week
- Use multiple desktops in Windows 10
- https://www.cnet.com/how-to/how-to-use-multiple-desktops-in-windows-10/
- In GIT, undo a rebase or a merge, or just go back in time
- https://haveibeenpwned.com/
BEEP.
This week in Dad Jokes … Programmer, err Engineer, um Developer Edition:
