3 ms·

A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinni

A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinning and things. Other bits sound nice but are back-end hell or licensing hell to implement. I try to get the program being able to be useful informative, easy for data entry, etc. After that - if I get the time - I can go onto enhancing other features like the style sheet (now that you got a good idea of what styles it utilizes its much easier to optimise the CSS to make it skin-able.) Integrations and import/export is a pretty nebulous thing, and if you are interacting with some proprietary system you are always needing to maintain the export/import code to stay compatible (not that easy). Depending on the format you may run into licensing issues to get interoperability, in others some of the local dev or external use tech might not be mature enough to implement well or correctly. "Just put an undo on it." "Detailed and up to date guides in text with screenshots at each step and highlights" Yeah. sigh If the development and team is mature these things will eventually happen. But then comanies fall back when they are riding high on just maintenance and loose the experienced members; then new devs that come in are so overwhelmed on the legacy codebase they just re-write from scratch, picking some bits to reimplement, and loosing a lot of others. Then again, you put a knowledgeable developer in to the planning process and they would surprise you "We could reorder this entry process here and cut more than half the time on data entry", "That report on the old system is redundant, here's why" and "have you ever thought of doing this cool feature? Because that would be so easy implement..."

mark-r 7y ago
I've found that Undo isn't something you can bolt on after the fact, you need to design with it in mind from the start. I've had very good outcomes with that approach.
- usmannk 7y ago
  Absolutely. See the meme of how IDA Pro doesn’t (didn’t) have undo for evidence of this.
- Doxin 7y ago
  Undo can be bolted on after the fact, but only if you had the presence of mind to either do event sourcing or if your application state isn't too big to store all your state centrally.
- ken 7y ago
  Why would Undo be any harder to add post-hoc than any other feature? Encapsulate each action, codify its opposite, and push it onto the undo stack.
  - mark-r 7y ago
    "Encapsulate each action and codify its opposite" is exactly the hard part of this. Too much code is written assuming it has access to the entire state of whatever it's modifying and doesn't have to worry too much about side effects.
  - buckminster 7y ago
    Most new features don't require changes to the logic of every existing feature.
ht_th 7y ago
> A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinning and things I have been here. Retro fitting a skinning / theming system afterwards invites all kinds of trouble as well. Ideally I would like to design for these customizations in a general sense from the start without spending unnecessary resources on implementing more than just a single style. At the very least, all configurable things should be injected into modules rather than be hard coded all over the place. Things like colors, fonts, language, and the like are obvious candidates, and if you have something for those properties, adding more later on might be easier anyway. But I am not sure how to sell this type of investment, though. In my experience, the aim is to get the product to the customer as fast as possible for the first couple of versions because we need to have paying customers to afford any further development.

mark-r 7y ago

I've found that Undo isn't something you can bolt on after the fact, you need to design with it in mind from the start. I've had very good outcomes with that approach.

usmannk 7y ago
Absolutely. See the meme of how IDA Pro doesn’t (didn’t) have undo for evidence of this.
Doxin 7y ago
Undo can be bolted on after the fact, but only if you had the presence of mind to either do event sourcing or if your application state isn't too big to store all your state centrally.
ken 7y ago
Why would Undo be any harder to add post-hoc than any other feature? Encapsulate each action, codify its opposite, and push it onto the undo stack.
- mark-r 7y ago
  "Encapsulate each action and codify its opposite" is exactly the hard part of this. Too much code is written assuming it has access to the entire state of whatever it's modifying and doesn't have to worry too much about side effects.
- buckminster 7y ago
  Most new features don't require changes to the logic of every existing feature.

ht_th 7y ago

> A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinning and things I have been here. Retro fitting a skinning / theming system afterwards invites all kinds of trouble as well. Ideally I would like to design for these customizations in a general sense from the start without spending unnecessary resources on implementing more than just a single style. At the very least, all configurable things should be injected into modules rather than be hard coded all over the place. Things like colors, fonts, language, and the like are obvious candidates, and if you have something for those properties, adding more later on might be easier anyway. But I am not sure how to sell this type of investment, though. In my experience, the aim is to get the product to the customer as fast as possible for the first couple of versions because we need to have paying customers to afford any further development.