Use cases, User Stories, Consulting, Documentation, Stories, SQLite3, Long Tail, Overfitting

Post date: May 20, 2016 4:42:18 PM

• Had long discussion about should we use specification, use cases or user stories, etc. All of those got it's advantages and are more useful on other cases than others.
• Had a consulting gig about the usual stuff: Documentation requirements, documentation sharing, weekly project checks. Some of the stuff I've written about earlier, but don't connect it right now here. Automated off-line mode and caching, with short timeout so that systems work even when there are network disruptions, systems also recover from those states fully automatically. Tasks in project need to be role based, nothing is 'personal', because it causes all the problems we know way too well. Basic invoicing, accounting, etc. Then the classic question when making ERP integration. Is invoicing sales? Or is it something which is going to be sales when invoices are paid and so on. Or is sales something which is only being paid using card or cash, or some other payment method which provides "instant payment" and carries virtually no risk of credit loss. Credit & Debit transactions with own issuer and external issuers. All kind of discounts, campaigns, etc. Data flow charts, exception handling. What happens if system is in off-line for extended periods? All the usual self service aspects using web and local terminals and so on. Where is master data kept for all of the multitude of data types required by the system. Multiple different ways of pricing, using algorithms, discount tables, complex discount tables with tons of rules, aka campaigns and of course there's option to use price matrix thinking. Basically price matrix is something which usually maintained by 3rd party system, because it's trivial to import price matrix but it's huge job to update it, especially if there are multiple dimensions. Sure, that matrix can be also sized in gigabytes but that's not a problem with current tech. It's always a good question if there's any simpler way to get required things done and if the all seeming complexity is actually required. Why is the pricing model such that it requires price matrix and if it requires it at all. Data Warehousing. It's seemingly simple, I just send data. But the actual problem is who's going to interpret it and if it's being done correctly. This is a point which basically easily makes me laugh and cry at the same time. Because it's so easy to fail it ridiculously badly. Then you're getting dis and misinformation instead of real data. Worst thing is that if the data never gets validated and 'the people looking at the numbers' think that the misinformation is real data. Does anyone know, who knows what we should know? The classic question. Is there anyone who actually knows what the requirements are? Nope, well, that's the norm. Actually it's awesome if customer acknowledges that they're having trouble to define the requirements. Worst fails are served when they're clueless about being clueless. System architecture, pricing models, integration design planning, stock management details. Well. How do you know you're good? When discussions lasting several days and going into detail won't bring anything surprising or new to the table. Been there, done that, can be done, no problem.
• That reminded me from a system integrator I met a long time a go in one meeting where we planned new integration. I gave him the documentation before hand and he studied it. Then we had a meeting to check up things. We went through everything and the guy was like, yep, ok, clear for everything. After that meeting I asked my colleague, what's your feeling. Did the guy understand everything or nothing at all? Because none of the questions gave any indication that he would understand the thing nor he said anything to show off the understanding. It's so easy to go to lesson about quantum physics and say, yeah, sure, I got it all, that's clear. When I didn't actually understand anything at all. But, in this case the trust was that the guy know what he was doing and delivered a week later perfectly working integration. - That's awesome! - I'm often getting this feeling in integration meetings. If the customer has prepared things well, there's rarely a need for extra questions. Which might easily give impression that I'm totally clueless. Yet, that's kind of fun at the same time. I'll let them think so if they want to. No problem. I'll just get the job done.
• With SQLite3 inequality filter data must be on right most index column when using composite indexes. SQLite3 indexing & query optimizer.
• Reminded my self about long tail and overfitting which are both quite obvious issues and nothing new. I just wanted to read what the Wikipedia articles say.