Home

January 8, 2007

the thingamy manifesto

1 Comment

Well done to Sig, for wri­ting The Thin­gamy Mani­festo, which is all to do with a new gene­ra­tion of enter­prise soft­ware he’s wor­king on i.e. Thin­gamy. He also inc­lu­des a ton of links, poin­ting to where these ideas are dis­cus­sed in grea­ter detail.
The mani­festo has ele­ven points. Here’s a tas­ter:

1. The Orga­ni­sa­tio­nal Hie­rarchy is kaput — as sin­gle pur­pose exe­cu­tor of the Busi­ness Model it requi­res reor­ga­ni­sa­tion every time you need to get bet­ter, an utterly futile exer­cise most of the time. Replace it.
2. Mana­ging is a waste of time. Lea­dership I need, get­ting out of bed in the mor­ning I can do myself.
3. Legacy soft­ware models the “way we always did things” — usually a model from the days of paper, quills and desks. Model rea­lity ins­tead.
4. Tree-structures are faulty. “Where it resi­des” is only two dimen­sio­nal and sui­ta­ble only for pla­ces. Use tags and any other means to enhance the know­ledge and make fin­ding easier.

Thanks, Sig!
[Disc­lo­sure: I have a small stake in Thin­gamy.]
[Mani­festo sub­mis­sion gui­de­li­nes are here.] [Mani­festo archive is here.]

One Response to “the thingamy manifesto”

1. Steve Borthwick says:

   January 9, 2007 at 7:57 PM

   It’s nice to hear about other small soft­ware com­pa­nies and their ideas, most firms seem to be too para­noid to share any (real) infor­ma­tion or vision during their deve­lop­ment pro­cess — you just get the same old cor­po­rate happy-talk (thanks for that phrase Hugh, I use it a lot!).
   I agree with all but one of these, I don’t get the big thing about tree struc­tu­res?
   What we try to do at my little soft­ware out­fit is to design a data struc­ture that’s rele­vant to the busi­ness pro­blem you are mode­lling (and ideally fle­xi­ble too — we rarely get it right 1st time!), if you need attri­bu­tes (or tags) and other descriptive/categorisation mecha­nisms then we try to design the data struc­tu­res accor­dingly.
   Ulti­ma­tely I see the “tree” bit as only how the underl­ying data struc­ture is sur­fa­ced in a U/I and so pro­vi­ding seve­ral dif­fe­rent ways to sur­face the same underl­ying data model is key to mee­ting all the various needs of pun­ters; pic­king on poor old trees seems a bit arbi­trary, why not reports, these seem to be much more widely “abu­sed” as vehic­les for data in my expe­rience?
   Just inte­res­ted..
   Cheers, Steve