Project Math

First there was arithmetic, then Algebra, then Calculus, Now we have...
Project Math

A few basic tenets
Estimated Cost = Amount of money we think the customer has to spend * Profit Multiplier

Profit Multiplier Factors
Repeat Customer = 3.5 (If they survived the first blood letting we need to raise our rates)
Government Agency = 3.0 (they can just raise taxes)
Large Multinational = 2.5 (If we don't over charge we will look cheap)
National Company = 2.0 (We will get the rest when they are a repeat customer)
Regional Company = 1.5 (Anything more might bankrupt them)
Small Company = 1.0 (not relevant we don't start the truck for less than 1.5)

How to estimate Hours per task

1. Take the Estimated Cost and divide by the Profit Multiplier to back out profit before anything else.
2. Divide the number of remainder by the number of task to get the per task cost.
3. Pick a number (the randomizer) between 1 and 10.
4. Order the tasks alphabetically and select every Nth task, where N = randomizer. Cut the per task cost in half for each selected task and add that amount to the task immediately following it in the order.
5. Return the tasks to their original order and then subtract N * 5 percent from the first task and add it to the second. Continue this process until you have cycled through the list at least twice.
6. Divide the amount from step 1 by your hourly rate * 2 to derive the estimated effort hours.
7. Allocate the hours proportionally based on the amounts from step 5 .
   

101 Ways To Know Your Software Project Is Doomed

1. Management has renamed its Waterfall process to Agile Waterfall
2. You start hiring consultants so they can take the blame
   
3. The Continuous Integration server has returned the error message “Fuck it, I give up”
   
4. You have implemented your own Ruby framework that uses XML configuration files
   
5. Your eldest team member references Martin Fowler as a ’snot-nosed punk’
   
6. Your source code control system is a series of folders on a shared drive
   
7. Allocated QA time is for Q and A why your crap is broken
   
8. All of your requirements are written on a used cocktail napkin
   
9. You start considering a new job so you don’t have to maintain the application you are building
   
10. The lead web developer thinks the X in XHTML means ‘extreme’
    
11. Every iteration meeting starts with “Do you want the good news or the bad news…”
    
12. Your team still gives a crap about its CMM Level
    
13. Progress is now measured by the number of fixed bugs and not completed features
    
14. Continuous Integration is getting new employees to read the employee handbook
    
15. You are friends with the janitor
    
16. The SCRUM master doesn’t really care what you did yesterday or what you will do today
    
17. Every milestone ends in a dead sprint
    
18. Your best developer only has his A+ Certification
    
19. You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR
    
20. Your manager could be replaced by an email redirection batch file
    
21. The only certification your software process has is ISO 9001/2000
    
22. Your manager thinks ‘Metrics’ is a type of protein drink
    
23. Every bug is prioritized as Critical
    
24. Every feature is prioritized as Trivial
    
25. Project estimates magically match the budget
    
26. Developers use the excuse of ’self documenting code’ for no comments
    
27. Your favorite software pattern is God Object
    
28. You still believe compiling is a form of testing
    
29. Developers still use Notepad as an IDE
    
30. Your manager wastes 7 hours a week asking for progress reports (true story)
    
31. You do not have your own machine and you are not doing pair programming
    
32. Team Rule - No meetings until 10 AM since we were all here until 2 AM
    
33. Your team believes ORM is a ‘fad’
    
34. Your team believes the transition from VB6 to VB.NET will be ’seamless’
    
35. Your manager thinks MS Project is the best management tool the market offers
    
36. Your spouse only gets to see you on a webcam
    
37. None of your unit tests have asserts in them
    
38. FrontPage is your web page editor of choice
    
39. You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC
    
40. The company motto is ‘Do more with less’
    
41. The phrase ‘It works on my machine’ is heard more than once a day
    
42. The last conference your .NET team attended was Apple WWDC 2000
43. Your manager insists that you track all activity but never uses the information to make decisions
    
44. All debugging occurs on the live server
    
45. Your manager does not know how to check email
    
46. Your manager thinks being SOX compliant means not working on baseball nights
    
47. The company hires Senetor Ted Stevens to give your project kick-off inspiration speech
    
48. The last book you read - Visual InterDev 6 Bible
    
49. The overall budget is mistaken for your weekly Mountain Dew bill
    
50. Your manager spends his lunch hour crying in his car (another true story)
    
51. Your lead web developer defines AJAX as a cleaning product
    
52. Your boss expects you to spend the next 2 days creating a purchase request for a $50 component
    
53. The sales team decreased your estimates because they believe you can work faster
    
54. Requirement - Rank #1 on Google
    
55. Everyday you work until Midnight, everyday your boss leaves at 4:30
    
56. Your manager loves to say “Why do the developers care? They get paid by the hour.”
    
57. The night shift at Starbucks knows you by name
    
58. Management can not understand why anyone needs more than a single monitor
    
59. Your development team only uses source control as a power failure backup system
    
60. Developers are not responsible for any testing
    
61. The team does not use SVN because they believe the merge algorithms are black voodoo magic
    
62. Your white boards are mostly white (VersionOne)
    
63. The client continually mistakes your burn-down chart for a burn-up chart
    
64. The project code name is renamed to ‘The Death March’
    
65. Now it physically pains you to say the word - Yes
    
66. Your teammates don’t refactor, they refuctor
    
67. To reward you for all of your overtime your boss purchases a new coffee maker
    
68. Your project budget is entered in the company ledger as ‘Corporate Overhead’
    
69. You secretly outsource pieces of the project so you can blog at work
    
70. A Change Control Board is created and your product isn’t even its first alpha version
    
71. Daily you consider breaking your fingers for the short term disability check
    
72. The deadline has been renamed a ‘milestone’…just like the last ‘milestone’
    
73. Your project managers ‘open door’ policy only applies between 5:01 PM - 7:59 AM
    
74. Your boss argues “Why buy it when we can built it!”
    
75. You bring beer to the office during your 2nd shift
    
76. The project manager is spotted consulting a Ouija board
    
77. You give misinformation to your teammates so you look better on your personal review
    
78. All code reviews are scheduled a week before product launch
    
79. Budget for testing exists as “if we have time”
    
80. The client will only talk about the requirements after they receive a fixed estimation
    
81. The boss does not find the humor in Dilbert
    
82. You start noticing your boss’s poker tells during planning poker
    
83. You start wondering if working 2 shifts at Pizza Hut is a better career alternative
    
84. All performance issues are resolved by getting larger machines
    
85. The project has been demoted to being released as a permanent ‘Beta’ version
    
86. Your car is towed from the office parking lot as it was thought to be abandoned
    
87. The project manager likes to doodle during requirements gathering meetings
    
88. Your SCRUM team consists of 1
    
89. Your timesheet looks like a Powerball ticket
    
90. The web developer thinks being 508 means looking good in her Levi Red Tabs
    
91. You think you need Multiple Personality Disorder medication because you are Mort, Elvis, and Einstein
    
92. Your manager substitutes professional consultant advice for a Magic 8 Ball
    
93. You know exactly how many compile warnings cause an ‘Out of Memory’ exception in your IDE
    
94. I have used IDE twice in this list and you still don’t know what it stands for
    
95. You have cut and pasted code from The Daily WTF
    
96. Broken unit tests are deleted because they are obviously out of date
    
97. You are sent to a conference to learn, but you skip sessions to go hunting for swag
    
98. QA has nicknamed you Chief Off-By-One
    
99. You are using MOSS 2007
    
100. You have been 90% complete 90% of the time
     
101. “Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too… thanks”

Originally found here:http://fun-dose.blogspot.com/2007/08/101-ways-to-know-your-software-project.html

How did you think that would come out?

I find myself wanting to ask that question more and more often. I have also noted a marked decrease in my ability to control myself and not actually ask.

Back in the good old days you could flash the resident software simpleton a quick “Shut up idiot” glance to prevent them from making everyone a little dumber with some nugget of dim-witted discourse. But today’s new breed of Fowlerites seem more immune to the tried and true moron mind control strategies.

Undaunted I move to Plan B. In this strategy we focus more on punitive action than on preventative measures. After the developer in question spends 3 hours “unfixing” the 3 minute “enhancement” I simply ask “What was best case scenario when you cooked up this plan?”

Seems to work, hope you find success with this method.

Refactor or Refuctor

Neither of these are actually words, however they seem to have similar meanings. Just some food for thought.

REFACTOR MAN

If you work in technology you have almost certainly met the REFACTOR man? There is one on every project with more than four team members.

You will recognize this guy as he runs around the office yelling "Refactor!!" It does not matter the problem, the answer is "refactor". (Note: as I type this entry the spell checker is indicating a misspelled word for refactor)

After several years of dealing with this omnipresent band of boobs I have decided to offer up a definition of refactor. My definition is as valid as any other since refactor is not actually an accepted word in the English language as defined by Webster (http://www.merriam-webster.com/dictionary/refactor), so here goes...

To Refactor is to take any piece of functional software and spend twice the time it took to originally write the software rewriting the software to conform to some "Pattern" (more on those in another entry). In and of itself this is not necessarily a bad thing, unfortunately the process of refactoring almost always costs more than it cost to build the damn software to start with when all the cost of testing and retrofit are considered. Let's not forget that in some extreme cases of refactoring functionality may change, or even disappear.

These small matters represent no consequence to REFACTOR MAN; the user obviously did not know what they were doing when they wrote requirements that did not conform to the patterns. Users are so stupid. The problem with every system can almost always be traced to some user doing something stupid like trying to use the system.

I would like to propose another potential source of the problem. Maybe REFACTOR MAN did not fully understand the problem he was trying to solve and went of half cocked and (predictably) came up with a half ass solution. Perhaps REFACTOR MAN was not quite truthful on his resume when he landed the job of senior developer or system architect and did not actually have the experience to know the best way to solve the problem. Maybe, just maybe, REFACTOR MAN should have read the entire Gang of Four book to understand the patterns before he started stealing quips and bits from Fowler’s bible on refactoring.

So the next time you are in a meeting with REFACTOR MAN trying to solve a problem in system B that has some minor dependence on system A and, true to form, he stands up and proudly pontificates the answer is to completely refactor system A. You should immediately rise from your seat, slap the taste out of his mouth, and calmly continue the meeting. Don’t hesitate, and for God’s sake don’t let him get to the white board. Once REFACTOR MAN starts to draw a sequence diagram his powers grow ten fold. If you don’t catch him before he gets to the board just leave the meeting, wait three to five minutes, and return. That is about the most time your run of the mill REFACTOR MAN can string together lucid and coherent thoughts in support of his position. If your REFACTOR MAN is particularly skilled in the black art of Ninja mind control tricks you may have to wait seven minutes.

It is generally best to just end the meeting at this point since the attendees will be slightly dazed from the complete vacuum of common sense created by the refactor rant. Don’t worry this will wear off after a few hours. After the meeting tell your supervisor you need a raise as you just saved the company twice the original cost of system A.

Just Bloggin'

Why would you do this?