Monday, September 29, 2014

Shared Models, Extending

Previously, while working on a logistics system, I encountered a situation where a service and a consumer of the service shared the same class, but within their own domain. Lets say it was a Shipment class for this example. The service returned A.Shipment where a is the namespace and the client used B.Shipment where B is the namespace of the client code. I didn't see it at the time, but what I might have done is to create a shared library that contained the object as a DTO which A and B could use. Each space would then extend or wrap the DTO to add domain specific logic - a decorator pattern could work. Instead I used an explicit cast operator to map the properties from B.Shipment to A.Shipment. This works, but is a clear violation of DRY.

Saturday, September 27, 2014

Ahhh.. javascript functions in scope of a function

Did you know? You can create a function in the scope of a function.
function doSomething(options,aName, bName}{
    function internalFun(a,b){
        return (a+b)/2;

    //or pass a function into a function
    var r = internalFun(options.a,options.getB());

    //but that assumes options implements getB and has a prop of a
    var s = internalFun(optiAonse], options[bName]);


Dependency Injection Usage

I put together a design to implement a request for a new feature yesterday via DI using an injection framework. Later, while pondering how I came to know about DI and DI frameworks, I realized that I probably would not have gone on that tangent on my own unless something really lead me there. For anyone unfamiliar with DI and/or DI frameworks, the benefits of DI are astounding so definitely learn how to use it. Study SOLID. DI is the D in the SOLID acronym. It means that anything which a particular class is dependent on is injected into the class by something else which knows how to do that. For example, if you have to send an email you could create an EmailManager class that consumes both an IEmailBuilder interface and an IEmailSender interface. The IEmailBuilder would simply have a GetEmail method that returns an Email object. And the IEmailSendable would have a SendEmail method, and possibly a SendEmailAsync method. So you could implement your standard emailing code and use SMTP to send the email. But also, you could send to a message queue such as msmq for some timed process to send batches, or you could write the email to a file or database table. The point is that there are several things you could do with the email. Each should be captured in it's own implementation of IEmailSendable. I smell a Factory pattern coming on here! The pattern of choice for this would be a Factory pattern since we don't know at build time which IEmailSendable to use. In this case, the factory is uses to inject the dependency into the EmailManager. The factory can be used to decide, based on whatever, which implementation of IEmailSendable to inject. This creates a separation of concerns and single responsibility in the classes involved. The EmailManager consumes the IEmailBuilder to get the email, then passes it to the IEmailSendable's Send method to send, file, queue or whatever implementation the Factory injects - perhaps the message delivery method will be looked up in a preferences table for each recipient and the same message will be delivered in different ways! It's all up to the implementation, although I would recommend setting up everything before returning the object from the Factory. It should be ready to send as soo, as SendEmail is called.

Tuesday, September 23, 2014

Take Time Off and Reflect

I took a long weekend to visit relatives and happened to have worked from home the week before due to an injury. Now, on my way back to office, I have a sense of perspective. Let's see what the rest of the week brings and how my perspective changes once I'm in the trenches again.

One thing I realized is that as a project usually involves several teams of people, knowing who is involved will be extremely important to the success of the project. I would assume that this can usually be known up front if time is taken for planning and understanding. For example, any need for a DBA on any project I've worked on was known early on. A proper plan will map this (possibly through some sort of activity diagram with swim lanes). It seems appropriate that each team has representation in the project kickoff meeting, especially from the person most likely to do the work.

This kind of plan requires participation in a project from a technical lead - the person who is responsible for designing the solution. Early participation can help determine an overview of the human resources needed for the project, especially if the technical lead is well-versed in the inner workings of the organization. After design, the needs would be more detailed - however, still not necessarily precise since design can change so much during build. The project plan needs to be reviewed and refined after this milestone.

Some questions to ask from each team that should generate tasks to add to the project plan:

How much lead-time do you need in order to plan for resources?

What information do you need in order to estimate effort?

How does one submit a request for work?

What level of involvement will be needed during the project?

This information should be available as part of the project documentation and should be tied to the tasks in the plan. A project plan should always map dependencies between tasks and between milestones.

Wednesday, September 17, 2014

Another way to quantify architctural layers in an enterprise sofware environment

Today, I watched a Webinar on how we can manage layers in the enterprise architecture. The webinar covered a technique that includes structures and guidance for managing and extending core systems by abstracting them and layering a middle tier and thin client tier on top of that.

The key takeaway for me was the timeline for change. Core systems generally change 10-20 years, middle 3-5, and thin client 1 year. Each layer in the architectural model mapped to a different development methodology - core is waterfall, middle is iterative, and client is agile.
The single most activity that provides the best value is to wrap the core systems to provide enterprise-wide abstraction.

In terms of approach, there were several prescriptions depending on the needs of each organization in terms of achieving the goals of addressing common concerns. One approach was to separate or create services into classifications : application, channel, and enterprise. Each approach is more costly, but offers more benefit of done right.

The speakers offered that the drivers of cost are related to management and governance. They cautioned to only build what is needed (a common theme in software development).

Several recurring themes in my view of software architecture for the enterprise were presented in the Webinar. This only further solidified and validated what I knew. Not to sell them short, because it also added to what I know. Brilliant work and a great presentation!

Wednesday, September 10, 2014

Software Craftspeople: Generalizing Specialists and Specializing Generalists

I recently came across a series of Agile essays and collections of knowledge about agile design, database refactoring, agile practices and more. After reading
by Scott W. Amber I started analyzing my own skill set and how it's grown over the years. I've always been more of a jack-of-all-trades sort of person, which I attribute mostly to a craving for mental growth.

The essay makes some compelling arguments for composing a team of generalizing specialists. Some of the arguments include better communications, more accurate knowledge which is shared amongst all members of the team, and less overhead - all of which result in better overall efficiency and more accurate results.

The author offers a case that having generalized specialists will result in reducing redundant documentation which in turn results in more accurate and maintainable documentation.

As for my own generalizing, I've been working on growth in terms of strategy, architectural diagrams, and planning. The hard skills in which I am strongest include RDBM, JavaScript, html, css and C# .NET. I have some skill in Java, nosql db, and VB.NET. In the realm of soft skills - I've been writing, growing my "business analysis skills" and improving communications overall.

Monday, September 8, 2014

let me map the way

I revisited my realization that I am visual-spacial and that I'm good at mapping routes. Much of the time, I'm very good at predicting time to destination too. This lead me to come up with a method of mapping out goals literally. Here's what I propose:

Map setup:
-a star in the center indicates now (current time and state).
-each goal is placed in sectors around the center at a distance proportional to the effort involved.
-each goal is sized proportionally to the value gained by achieving the goal.
-paths should be marked using lines drawn as directly as possible from the center star to each goal.
-goals that can connect directly, should also be connected via straight lines.
-the connections should represent possible routes.
-if the goals are too close so that the proportion of the line does not reflect effort, add more lines or use curved lines so that the total distance is equal to relative effort.

-routes can be drawn over the paths that connect the points to plan the best route.

-indicate obstacles with roadwork signs, roadblocks across the path, whatever else you can come up with to show slowdowns, blocking, etc.
-use dotted lines to indicate unknowns
-can label landmarks, unknowns, whatever using map keys, or tag with a number and show detail referenced by the number or letter-number combo

I will need to create a sample to include that in this post later, if I don't get back to it it's because I didn't map the way...

This could potentially be automated and read from different sources of data with appropriate mapping to the source fields.

Thursday, September 4, 2014

build v buy

Do you build or do you buy? Pros and cons related to software, hardware and talent.

The common case, on the surface, is software. Starting there, the pros and cons for build and buy can be weighed against current business cases and a determination can be made based on specified criteria.

Some pros for buy are decreased time to production, reduced internal management and support, field tested. Of course all of these are dependent on the product, your share of their market, your contract, and the internals and stability of the vendor. The cons include unknown internals, shiny advertisements-dull product, limitations to change, dependent upon stability of vendor company. Again, much of this depends on the vendor, product, and your company's relationship with the vendor.

Some pros of build depend mostly on internals and include build to suit, future change can be supported, issue mitigation can be reduced. All of these depend on staffing and management. Work can be outsourced to a consulting firm, but you'd lose some benefit of having full internal control and domain knowledge. Cons include internal staffing and management, continued costs.

When it comes to software, I am definitely build over buy. But, in some cases products with great APIs and well known products, documentation, and support can be great!

A second, lesser thought of case is in terms of personnel. The old cliche "good people are hard to find" may or may not be true depending on your perspective, but good people are not hard to build. It just takes a good organization to build good people. Once they're built, you want them to continue working for you even if they are working elsewhere. This requires a new way of thinking about work and employees.

Pros of buy - instant ninja, do not have to invest in training programs, experience.
Cons of buy - carried over attitudes and ways of thinking (inflexible), unknown experience, no historical working relationship.
Pros of build - can tailor skills to needs, strong relationships, domain knowledge.
Cons of build - may not prove fruitful,  might take skills elsewhere, takes time

Building employees must be a continuous cycle - recruit from colleges or other, training, exercising, etc. If the employee gets some buy in in the company, they will continue to work toward improving themselves and the company. Especially if they understand that the results of a company becoming more successful means that they will become more successful. That kind of buy-in (ownership) also means that employees would be more likely to stick around at their own company.

Set up the right kind of environment where people are brought up and ingrained into the organization and you will have a good thing - just keep doing it right.

UML Documentation: diagramming an existing application

I began creating diagrams of a system today that has very minimal diagrammatic documentation. There are many word written, but any person who is new to the system would have a high learning curve in order to get caught up.

The diagrams are the beginning of the development design and planning phase of a project. I will be working with a new developer, albeit far more experienced than I am, on this project. I worked on this application during a previous project and have been supporting it as well.

For some time I have had the goal of learning documentation techniques. Recently, I watched a PluralSight  training video titles "Introduction to UML". I took studious notes and am now putting the new knowledge into practice. I have no guide, so I'm certain to make mistakes, but perhaps it is better to get that sorted out now so that I can begin to improve.

I started on paper, then using Visual Studio Ultimate 2013 I created a Modelling project in the TFS Team Project folder that contained the application. I added a Use Case diagram and transferred (by re-creating) the core use cases into a single usecasediagram. Next, I created a high level component diagram of the whole system - which has several moving pieces.

This takes a bit of time, but not much. I was especially efficient since I was able to reference my notes and having gained much better understanding from the video. I saw a previous diagram of mine and recall how long that took to produce because I had no idea wtf I was doing. Now I have at least some frame of reference.

Still, that crappy diagram was useful enough to convey much about the system to a BA who had not yet worked with that system. Without the diagram, it would have been really difficult to communicate about all the moving pieces.

When the new developer is on the project I'm hoping that there will be a similar experience in terms of being able to communicate with the aide of the diagrams I produce. I liken them to having maps when dropped in the middle of a forest. Now all we need in a compass, better yet - GPS!

Communications Confusions

I learned today that ineffective communications can lead to a great deal of confusion. Often, the case is that a little bit of taking a step back can clear up much of this. A colleague asked me to do something that goes against the grain of what the team as a whole has been striving to improve. This lead me to put up resistance to the request.

As we talked it out we came to find that we were saying the same thing, but from a different perspective. Turns out the root of the issue was the colleague's unfamiliarity with a tool that we are using was causing some confusion. This is actually quite common with this specific tool which has lead to too much confusion over the years.

Other things came out of that conversation about some process changes that were not communicated; also, which not a single member of the development team was involved in. Wonder what the downstream effects of that will be...

I'm a fan of communication and collaboration, without which there will certainly be difficulties in maintaining the processes which are created.

Tuesday, September 2, 2014

Experienced || Good

In certain ways, I'm finding that developer experience in years does not always translate to better code, use of OOP, or better design/architecture.

Granted, I'm sure the world is full of top-notch developers. But for every one of those, how many are just filling seats and creating more slop? How do we bail the profession out of this? It's up to us a professionals to continue to study and educate ourselves and each other about our craft - never mind our past education and experience; or that of others. We can learn something new from anyone!

I post here to teach but also to learn.