4 ms·

Timekeeping systems are actually extremely complicated. EXTREMELY sophisticated. The level of detail it takes to get one right is painstaking, and it is key t

Timekeeping systems are actually extremely complicated. EXTREMELY sophisticated. The level of detail it takes to get one right is painstaking, and it is key to a city's survival. It's complex enough that you wouldn't understand it, nor would any auditor. For that reason, I just started a new startup company: TimeKeep NYC. We specialize in timekeeping software for NYC area cities. Looking for employees now, especially ones who aren't snitches. Based on past products in this market, I think we can do quite well.

jerf 15y ago
To be fair, timekeeping software really isn't as trivial as you might like, at least assuming that we want to move beyond the raw recording of who worked when out into actual management of such things. Requirements come from federal, state, and local laws, as well as negotiations with all relevant unions. So even before you've gotten to the usual BS requirements laid on by management, you've already got a large pile of requirements that A: are legally mandated and B: written without so much as five minutes consultation with a software engineer. But, yeah, on the other hand that's just the usual business software story. 10x budget overruns are probably not called for.
- ams6110 15y ago
  But, really.... timekeeping and payroll were some of the FIRST business applications developed. It's a solved problem at this point, even with all the nuances. Developing this from scratch for NYC seems like the epitome of reinventing the wheel.
  - mattmanser 15y ago
    No enterprise software is a solved problem yet, there's a lot of bad software dominating at the moment (look no further than sage for accounting for example), any enterprise software you randomly pick will suffer from at least one of: - Have bloody awful UIs - Aren't extensible - Need a massive amount of expensive consultant days to setup - Are very brittle - Have an overwhelming list of features which make them very hard to use - Have bizarre restrictions on certain data (e.g. max 100 chars for a comment) - They're not capable of talking with common system X - Don't expose an API - Have atrocious db structure making reporting extremely expensive in dev time - Use a home rolled DB (oh. god. no.) As for the problem of timekeeping being extremely complex, it's not at all. It's difficult, but solvable with one or two decent developers/project managers in a few months. I know as I've seen it done twice now. It's only extremely complex if you try and include every weird quirk and feature that every client has ask for. Sometimes the solution isn't extending the software, it's changing the business process or simply leaving them on the old paper system. If you take a 37signals-esque path you've got something that'll sell to 80% of businesses, let niche software cover the rest.
    - jerf 15y ago
      "It's difficult, but solvable with one or two decent developers/project managers in a few months. I know as I've seen it done twice now." It was actually my first task that I ever did "for real", though we did only the raw recording; the processing was done by older code that had all the quirks built in. It was a success, too. The problem itself is easy, but it's definitely in the class of things that can be made arbitrarily hard by added requirements with no thought given to costs/benefits. Fortunately on my project, the devs and the management were on good terms, so much thought was given to cost/benefit tradeoffs, but I can easily see cascading failure in a different environment. Even the easiest software projects can and are sunk by that.
    - jfruh 15y ago
      "If you take a 37signals-esque path you've got something that'll sell to 80% of businesses, let niche software cover the rest." Er, has it occurred to you that the insanely convoluted world of NYC government might constitute a niche?
clistctrl 15y ago
I'm curious, what are some of the complexities involved in a timekeeping system?
- bane 15y ago
  In this case, one of the issues was that worker's were incensed over biometric scanners proposed for the system intended to fight pervasive time reporting fraud. http://www.citylimits.org/news/article_print.cfm?article_id=3513 http://www.citylimits.org/news/article_print.cfm?article_id=... (article from 2005 when it was only 6x over budget)
- ams6110 15y ago
  Things like varying overtime rates depending on time of day, accumulated hours, whether it's a holiday, different rates for depending on specific work assignments, etc. It's not as simple as a flat rate x number of hours. But it's nothing that hasn't been done before, either.
  - smokeyj 15y ago
    At first I was like, "wow this would take me five minutes to program". Now it's looking like a solid 20 minutes.
    - deleted 15y ago
      [deleted]
    - derpaderp 15y ago
      You say that now. Try writing a real world app some time.
    - deleted 15y ago
      [deleted]
  - rluhar 15y ago
    Agreed. You also have to think about who can approve the hours booked. So you would need to have some sort of hook into the HR / Org database which determines each users entitlements. It gets very very complicated! Technically, the problem is nothing new. The difficulty lies in designing the system and getting it to work correctly with an organizations existing business processes and systems.
billt 15y ago
They are more complex than this. Not just anyone can start a company to provide 99.9% reliable enterprise-level management of this problem. A recent study indicated that a major city would have to spend at least $100M to tackle this systemic issue. NYC's mistake was trying to cut corners with $60M.
- deleted 15y ago
  [deleted]
bmelton 15y ago
Have you already looked into DCAA compliance? If not, your system can't be used for any federal systems, and likely aren't available to be used by most state and municipal government agencies.
- lylejohnson 15y ago
  I'm going out on a limb and guessing that kenjackson (grandparent post) was kidding about his new startup.
anon7865 15y ago
> especially ones who aren't snitches The brazenness...only in NYC. Also, if you ever get in the position of saying "X is extremely complicated and I can't explain it to you" it is because you stand to benefit by designing a system poorly, or you aren't bright enough or don't have the experience to realize that you can reframe the problem. Algebraic geometry is also complicated, but these days there are plenty of books that will explain it to you, and the tools (like sheaves) are well-established and standard. Obfuscation is the MO of installed, configured enterprise software. If there were an incentive to create a simple, effective solution, then, lo and behold, one would be created. The incentive is almost never there. Take Unix for example. It is simple and effective (and flimsy as all heck) but before it came along, obtuse operating systems were the norm. It is worth pointing out that A) Thompson and Ritchie are geniuses and B) there was no financial incentive.

jerf 15y ago

To be fair, timekeeping software really isn't as trivial as you might like, at least assuming that we want to move beyond the raw recording of who worked when out into actual management of such things. Requirements come from federal, state, and local laws, as well as negotiations with all relevant unions. So even before you've gotten to the usual BS requirements laid on by management, you've already got a large pile of requirements that A: are legally mandated and B: written without so much as five minutes consultation with a software engineer. But, yeah, on the other hand that's just the usual business software story. 10x budget overruns are probably not called for.

ams6110 15y ago
But, really.... timekeeping and payroll were some of the FIRST business applications developed. It's a solved problem at this point, even with all the nuances. Developing this from scratch for NYC seems like the epitome of reinventing the wheel.
- mattmanser 15y ago
  No enterprise software is a solved problem yet, there's a lot of bad software dominating at the moment (look no further than sage for accounting for example), any enterprise software you randomly pick will suffer from at least one of: - Have bloody awful UIs - Aren't extensible - Need a massive amount of expensive consultant days to setup - Are very brittle - Have an overwhelming list of features which make them very hard to use - Have bizarre restrictions on certain data (e.g. max 100 chars for a comment) - They're not capable of talking with common system X - Don't expose an API - Have atrocious db structure making reporting extremely expensive in dev time - Use a home rolled DB (oh. god. no.) As for the problem of timekeeping being extremely complex, it's not at all. It's difficult, but solvable with one or two decent developers/project managers in a few months. I know as I've seen it done twice now. It's only extremely complex if you try and include every weird quirk and feature that every client has ask for. Sometimes the solution isn't extending the software, it's changing the business process or simply leaving them on the old paper system. If you take a 37signals-esque path you've got something that'll sell to 80% of businesses, let niche software cover the rest.
  - jerf 15y ago
    "It's difficult, but solvable with one or two decent developers/project managers in a few months. I know as I've seen it done twice now." It was actually my first task that I ever did "for real", though we did only the raw recording; the processing was done by older code that had all the quirks built in. It was a success, too. The problem itself is easy, but it's definitely in the class of things that can be made arbitrarily hard by added requirements with no thought given to costs/benefits. Fortunately on my project, the devs and the management were on good terms, so much thought was given to cost/benefit tradeoffs, but I can easily see cascading failure in a different environment. Even the easiest software projects can and are sunk by that.
  - jfruh 15y ago
    "If you take a 37signals-esque path you've got something that'll sell to 80% of businesses, let niche software cover the rest." Er, has it occurred to you that the insanely convoluted world of NYC government might constitute a niche?

clistctrl 15y ago

I'm curious, what are some of the complexities involved in a timekeeping system?

bane 15y ago
In this case, one of the issues was that worker's were incensed over biometric scanners proposed for the system intended to fight pervasive time reporting fraud. http://www.citylimits.org/news/article_print.cfm?article_id=3513 http://www.citylimits.org/news/article_print.cfm?article_id=... (article from 2005 when it was only 6x over budget)
ams6110 15y ago
Things like varying overtime rates depending on time of day, accumulated hours, whether it's a holiday, different rates for depending on specific work assignments, etc. It's not as simple as a flat rate x number of hours. But it's nothing that hasn't been done before, either.
- smokeyj 15y ago
  At first I was like, "wow this would take me five minutes to program". Now it's looking like a solid 20 minutes.
  - deleted 15y ago
    [deleted]
  - derpaderp 15y ago
    You say that now. Try writing a real world app some time.
  - deleted 15y ago
    [deleted]
- rluhar 15y ago
  Agreed. You also have to think about who can approve the hours booked. So you would need to have some sort of hook into the HR / Org database which determines each users entitlements. It gets very very complicated! Technically, the problem is nothing new. The difficulty lies in designing the system and getting it to work correctly with an organizations existing business processes and systems.

billt 15y ago

They are more complex than this. Not just anyone can start a company to provide 99.9% reliable enterprise-level management of this problem. A recent study indicated that a major city would have to spend at least $100M to tackle this systemic issue. NYC's mistake was trying to cut corners with $60M.

deleted 15y ago
[deleted]

bmelton 15y ago

Have you already looked into DCAA compliance? If not, your system can't be used for any federal systems, and likely aren't available to be used by most state and municipal government agencies.

lylejohnson 15y ago
I'm going out on a limb and guessing that kenjackson (grandparent post) was kidding about his new startup.

anon7865 15y ago

> especially ones who aren't snitches The brazenness...only in NYC. Also, if you ever get in the position of saying "X is extremely complicated and I can't explain it to you" it is because you stand to benefit by designing a system poorly, or you aren't bright enough or don't have the experience to realize that you can reframe the problem. Algebraic geometry is also complicated, but these days there are plenty of books that will explain it to you, and the tools (like sheaves) are well-established and standard. Obfuscation is the MO of installed, configured enterprise software. If there were an incentive to create a simple, effective solution, then, lo and behold, one would be created. The incentive is almost never there. Take Unix for example. It is simple and effective (and flimsy as all heck) but before it came along, obtuse operating systems were the norm. It is worth pointing out that A) Thompson and Ritchie are geniuses and B) there was no financial incentive.