Monday, August 22, 2016

Decentralization of Business Tasks to Build in Better SOC

In the typical business organization, there are departments which specialize in specific business areas - HR, IT, Marketing, etc. To me this seems to be a benefit due to the specialized nature of each. There may be individuals in each department who have a knowledge and passion of another area and there may be some crossover, but by and large the units are siloed in their work - especially at larger institutions. Since the structure of systems have a tendency to model the structure of the organizations that create them (see Conway's Law) and many systems that tend to the needs of these units will provide some similar capabilities, it is up to the system designers at the enterprise to go against the natural tendency to design the systems along the same lines as business structure and design the system along the lines of capabilities. There are several benefits to doing so as described in this writing.
Reason 1: DRY - Do Not Repeat Yourself. This is a mantra of software development. This practice of not repeating yourself is commonly declared as a time saver as well as a defect deterrent, especially when there is a change in requirements for a feature. Consider a number of systems who have users and a user admin feature. During the course of development of this feature for each application a considerable amount of time was spent gathering requirement, doing mockups, designing, implementing, testing for this feature in EACH system. And when a defect is found, or security requirements change each system must be updated in turn. However, if DRY were applied at the enterprise level, there would be one user admin capability. That user admin would have behaviors designed to provide common functionality with respect to administering users - add/remove, assign role, change role, reset passwords, etc. The immediate benefit is that the features wouldn't have to be developed for each application. Other benefits are centralizes administration of all applications for system admins. Additionally, this enables "One level up" features to be developed where users can have access to all their applications centralized. One thing to consider with this design is the impact on individual applications due to changes to core features. Additionally, the system must be robust but flexible enough to allow extension by other systems. For example, a canned(packaged) solution may offer an API to its user administration. An idealized core user admin would be able to adapt to it so that it could also be administered centrally.

Reason 2: User Efficiency. Users are able to access actions, tasks and tools from a common location. Potential for more efficient interaction with technology.

Reason 3: Change. Centrally managed change. Changes happen in one place. Easier to find what is impacted by a change.

Tuesday, May 24, 2016


Having recently delved into a world of conversational machines in the form of chat bots, I've learned a few things about that world. There are so many platforms with so many options to choose from, but there are some common threads.

One common thread is that there are different AI technologies that can plug into a chat bot. Two of those are language interpretation and psychological profiling. Language interpretation uses a series of mappings to determine the topic(s) of a user's statement. Psychological profiling uses data gathered from social media to guess what a person's personality traits are. Combine these with some other sources including a series of waterfall questions and you can tailor a bot to give personalized responses to the user.

Imagine having a bot app on your device or computer that monitors your activities and responds to your needs! Bot apps can be programmed to launch programs and run tasks. I'm not constructing a world where the bot takes commands and executes them, but a world where the bot truly learns your behaviors and serves your needs by executing tasks when you need them!

Do you open a certain program everytime a certain person calls? Do you need to dial in to a meeting when it begins? Do you spend time on Facebook every morning? How about composing emails? I'm not suggesting chat bots should do all this for you, rather that the technologies behind chat bots can and should automate some of the most routine and mundane aspects or your life so that rather than being a slave to the machine (email, launching programs, dialing phones, scheduling appointments) the machines can be your servant and assistant.

Monday, May 2, 2016

JavaScript Fun: Method of Wrapping JQuery getJSON to Handle Errors to Avoid Duplicated Code

Here's a great way to wrap JQuery and other libs in your own wrapper so you don't have to repeat yourself, repeat yourself. It's pretty basic and simple for now.

JS Bin on

JavaScript Fun: how to merge two objects, no recursion yet...

I like using objects in javascript. This is a basic and easy way to merge two of them. Good example is if you take in options into something.

JS Bin on

Saturday, April 23, 2016

5 Year Old and Recursive Algorithms

Just witnessed my son (who is 5 years old) programming a recursive algorithm (tail recursion) in a game called Light Bot on his iPad. Light Bot is a game where you line up a bunch of commands into a program that controls an on-screen robot.
The objective is to light up the blue squares on a board. There are commands to move forward, turn left, turn right, hop, light the square, and run a procedure. There are various layouts of squares, and numbers of commands and procedures that can be used to complete the challenges. Apparently he's made it to the challenges that require recursion in order to complete the levels. So proud!

Friday, April 15, 2016

Making Progress

Some recent thoughts on reward systems: 

The best approach is to have people choose their own benchmarks for rewards and their own rewards - sort of like personal goal setting. I watched a TED talk on the topic of rewards, some research showed that rewards for performance in knowledge work do not get better results - of course we all like rewards anyways. If the reward system is more intrinsic, as the research suggests, then I might be inclined to choose something to be rewarded for like self-improvement in some way. But the rewards for self-improvement are natural and intrinsic, not extrinsic like a trip to the vending machine or a piece of paper with a fancy border. Then it boils down to this - how do you get others to do what you want them to do? Or better yet, how to get others to behave in a way that provides the best benefit of the group (the organization).

First thoughts are that having the knowledge of the goals of the organization will allow individuals to come to the same conclusions. In this way we can clearly see and understand the costs and benefits of our actions. For example, if I know that we need to keep the Project A work light because I have all the information -  Product A is reaching end-of-life, we have other things to work on, and Project B is consuming more time than expected - then I can make decisions and act accordingly. Without it I cannot.

Lets take a concrete example where progress is straightforward to measure like digging a ditch. In order to measure progress and have some regular motivation and rewards for achieving goals, we might mark daily goals along the path of the future ditch. That would be a clear visible goal and that mark for can be set for each day according to the time available to dig the ditch. It would be relatively easy to take the length of the ditch and the total time available and divide it evenly. You’d also have to know how much ditch can be dug by the digging team each day. And then there's the real world with its chaotic factors that would affect the overall progress.

I'm not a ditch digging expert by any means, but I have dug a trench or two. Drawing on my limited experience and the power of imagination let's think of a few things that could affect the progress of a digging team. Soil texture - soil rich in clay is harder to dig through than silty soil, rocky soil would difficult as well. Weather - should be obvious. Obstruction density - tree roots, utilities, garbage, old-roads, etc. Health issues, injuries, equipment quality, people, alignment of the planets, etc...

With all of the potential causes of impedance to progress, unless something is obvious (thus preventable or unavoidable), tracking those daily goals will be important to maintaining the pace needed to dig the whole ditch. If the digging team is not meeting the goal for some particular day, how do you solve that problem?

Step one: Find out what the problem is. Why is the digging team not meeting its potential? Without that, you got nothing. Can't treat it like a black box and throw out things you think might work until you find something that does. Well you could, but that could do more harm than good.

Step two: See if the team knows the solution. Often the people doing the work will have an answer that works for them. Perhaps the issue is tree roots slowing them down. They might not have the tools they need to clear them out efficiently.

Step three: Implement the solution. Get the tools, people, system, whatever in place in order to get things on pace.

Sunday, April 3, 2016

Contain Dependencies

This has come up several times in various applications I've worked with. You have some dependency - lets say the MVC framework for example. That dependency is a certain version, lets say 4 for sake of discussion. You have multiple csproj files in your Visual Studio solution. One of those projects is the ASP.NET MVC 4 web project, another is a bunch of models, maybe another contains a collection of helpers. One of those projects which the web proj depends on also depends on MVC, but also has some other dependencies like StructureMap or NHibernate or Automapper.

Now imagine one or more of those projects is shared amongst multiple solutions since it contains re-usable code. If any of those projects have a 3rd party dependency updated to the latest (and greatest?), what happens to the shared project? It too must be updated. Once that happens, all other solutions which use it are impacted. But what if the consuming code doesn't even use the feature that depends on the 3rd party lib? Now you're stuck holding the bag anyways...

So here's the lesson - if you're writing a lib that is intended for re-use, separate any pieces of code that have external dependencies onto their own assemblies. For example, of you have a library of helpers, have a library of core helpers then a library of helpers for each other external dependency.


Maybe even version them if you see fit.


By separating those dependencies this way, you can avoid potentially crippling issues down the road where suddenly your applications won't compile and you don't know why. When you finally find out, you have to wade though oodles of muck to sort it all out. Plus its just good SoC :)

Happy Coding!