Thursday, May 28, 2015

TDD - Test-Driven Design

TDD, TFD, BDD, ATDD...all of those should be read x-y Design and not x-y Development. It would clarify the real value in doing development this way. However, it may seem if this is true, then the only tests that really matter are the BDD and ATDD tests. This would violate the testing pyramid where most tests should be Unit Tests. All systems do one thing, respond to input in some way. The response usually results in some state change and/or some other actions that also result in a state change. Example: User completes some task, task should be marked complete. Upon completion a communication should be sent to various recipients. That example contains so many assumptions that when one begins to design the feature, it would be impossible because the design is not yet specified. Enter BDD. First step is to set up the pre-conditions: User has a task that is in state InProgress. User completed form. Form passed validation. There are subscribers to the completion event. The subscribers are listed as follows: Josepha in accounting via email j.doe@example.com The Budgeting Dept via some other application Etc etc etc. Next is to describe the action that causes a change. User marks task complete. Last is to verify the result. Task status is complete. Email sent. Budget app data sent. Etc etc etc In this way the requirements are not ambiguous and all the scenarios are easier to understand. We have a better starting point to design our system.

Tuesday, May 26, 2015

SPA Framework Templates Have No Reuse

For all the comparisons of SPA Frameworks I haven't seen much focus on the templating. There's a common complaint that all templating systems have drawbacks. One that I've not seen considered is that the templates are very specific to the framework. Wouldn't it be nice if the templating engine was truly a separate concern? Then when you build an app with a template you can keep all your markup when things change. Each framework does templating in its own way. Angular has you creating your own tags, Ember uses Handlebars markup, React seems to mix JavaScript and html-as-a-strig, Knockout uses data- attributes. All of these have their drawbacks, however consider if you or the developers of the framework are going to change the M/C/VM engine or perhaps go to the next framework. What amount of rework does that introduce? It would be nice to grab your favorite templating engine off the shelf, hook that into your favorite router, then add your controllers with a bit of DI and config everything works! Whether you like the ng-whatever syntax, the purity of data-bind, or the separation that {{item.name}} provides, or how about Jade with its minimalist markup? Then there's Express, Mongoose, Jade how about that! Grab a template engine (Jade), a router/controller (Express), and a model engine (Mongoose), run them all on Node and hit go! I have to have a better look at this!

Thursday, May 21, 2015

Change is Good, as Long as its Not Big Changes all at Once

Today's lesson is about change. When we make big impactful changes, they may backfire in the long run especially if they do not leave options on the table. If change is desired, find a way to make a small change that can be built upon in a number of ways. View change as growth that happens gradually without notice. In that way, it happens without too many growing pains which can result in change viewed in a negative way. For example, if you are changing to introduce a new technology that will help productivity, try to find a way to roll it out and have a few champions work with it for a bit and spread out the word gradually rather than shoving it into the hands of everyone all at once. In the long term, acceptance and usage will be much better.

Monday, May 18, 2015

Budget as a Team!?

Would it work? Can the team manage a budget as a team? Nothing says empowerment like giving responsibility of managing money. So why not give the team a budget to manage? If course things could really run afoul and it's easy to imagine how, but lets focus for a bit on the potential benefits. A sure benefit is that the team would have full exposure to the workings of the budgeting aspect of the business. How often are asks denied or ignored because they would "cost too much"? Of course, the team may have some great ideas about how to improve things and they may carry a cost. Often enough, denial of perfectly good ideas can be detrimental to morale. In this case, the improvements would be weighed against the budget and more innovative approaches may emerge. More importantly, morale crushing would be based on reality instead of "because I said so". Approve budget increases and supplements. There's no sense in implementing a strategy of giving the team a budget without allowing for necessary increases and approvals. Of course the team would have to show why this is necessary, but that's what managers would need to do anyways. If the team has to ask the manager first, unless the manager is fully ingrained in the team and understands the needs, there may be much lost in translation. Who knows best about how a team can function better than the team? That is, unless you have a bunch that just doesn't love what they do. In that case it's time to revamp. If you have the right people, they will be more than willing and plenty able to make decisions responsibly given the information and proper authority. The role of the manager in this case would be to understand the priorities and set the goals. Imagine that your job is to plan a weekend trip to build a team. The trip would include challenges that the team would have to overcome by working together. What challenges would you devise for them? Who would emerge as leaders? Who would glue the team together? Who would provide moral support? So much of the team dynamic would emerge from such a weekend! What if that dynamic could exist every day! One way to challenge a team regularly in the office could be through continual planning in the area of improvement! This can be even more of a challenge if the team is responsible for the budget allocated toward improvement. As far as implementing this Budget as a Team approach, a manager may be inclined to give this a trial run with a portion of the budget...kudos! Just keep at it for consecutive budget seasons, allow for some mistakes, and celebrate successes! When things start going well, increase application. Set the course. What if you notice that there is a lack of knowledge in certain areas within your team? How can you address this through setting up a challenge for the team? Why not put it to the team? Set a budget, have the team work on the problem, be open to them asking for more if needed, they will justify it. Even if the justification seems outrageous. If the funds are not available or cannot be allocated, show them why. Perhaps they will be able to find other means of obtaining funding, or they will modify the solution. I would love to hear from anyone who has done this. Did it succeed? Share your success stories! Did it crash and burn? What was the root cause of failure? How can others do better? Is this strategy just simply bound for failure? Why? Why? Why? Why? Why?

Wednesday, May 13, 2015

The True Value of Test First Development (TDD)

This week I was able to show someone the true benefits of test first, actually we are doing a form of Behavior Driven Development (BDD). With respect to one of the true values of writing test first though, its all the same. You may think the true benefits are defect free code, change with confidence, and isolation of modules. You'd be right of course that these are benefits, but there's more - design and efficiency. We stayed the course for a bit with respect to writing tests first, but at the pleadings of the mentee I decided to just bang out some code as an experiment. We talked about a design for the API function that we were designing and I went ahead and wrote the interface and implemented it. Then we circled around to the tests and began to change them to suit our new implementation...that's when the proof showed up in the pudding! It turns out that our design was not going to work out so well. We wasted time writing it and now we had to waste more time retrofitting the tests. The only thing to do was to start with the test, write the interface we needed, then redo the implementation. When we start at the end, we know how to go best.

Tuesday, May 12, 2015

Peopleware

I want to spend time to blog about a few things I learned today, but reading Peopleware (Tom DeMarco and Timothy Lister), a book about the follies of conventions of management in software and how to improve everything from performance to retention has got my attention these days. The main theme so far seems to be focused on workspace, however it touches on dress code and personality. It's all about how the corporate culture is crushing performance and throughput in software and similar fields where focus and innovation are keys to success and what changes need to happen to revolutionize the industry. It's been around awhile and is in its third edition. I've been recommending this book to everyone. I'll get around to all of the other great lessons learned in a few days time...

Friday, May 8, 2015

On SOC

Today, I mentored a coworker on Separation Of Concerns commonly SOC. We are working on a bit of a pet project that he has some cobbled together code for. Instead of working directly with that we are starting from scratch and building out the features one at a time.


One concern we encountered is that each user has their own collection of widgets that they do something with. Some users may have the same widgets among their collections of widgets, but the widgets themselves belong to no single user.


We broke out a completely bounded context of User Settings. Though some information may cross the boundary into the Widget World, the only thing that shall pass is immutable data. In this way we have user settings that involve widgets and any other number of concerns such as app theme, gadgets, notification settings, etc.


Given that we are taking this on as a learning experience, we decided that we would (in the style of Clean Code) hold off on deciding persistence. What we do have is an object that loads UserSettings and one that saves it. Why the separate objects? Actually we have separate contracts, that's the part I do care about. The implementation can be the same for now. What the read/write separation is a out is control. It costs little to separate them now for the possible migration of the implementation to services later. It may be a bit crufty, but I can live with it in this case.


More central to the tier of persistence, is the layer of UseCase informed logic. In our case we have different concerns for user settings. One is centered on widgets, another on gadgets, another on application look and feel. There could be others. Each of these will be separated into their own bounded contexts of sorts. We are using the term Manager to describe this layer.


So we have a Manager for each concern - widgets, gadgets, app settings, notifications, etc. Any given Manager could talk to any data access context (Resources). Say a user adds a widget to his/her list of widgets that they want to have a look at. The Manager consumes the User Settings resource - loads settings, adds widget id to user.widgets, calls resource to with save method passing UserSettings object to method. All details of saving are abstracted from the business logic by the resource. The resource could be saving to a file, an RMDB, a document store, or some newfangled thing. We can change that without affecting BL.


If we have an app setting like 'theme' we can follow the same practice. Add theme id to the UserSettings object, make a ThemeManager or add methods to the UserAppSettingsManager and call the same load and save methods in the UserSettingsResource. We may have that same manager talk to the AppSettingsResource to load specific details about the theme. Likewise, the WidgetManager would load widget data from the WidgetResource after loading the list of widgets for the user from the UserSettings resource.


This type of pattern allows separation of concerns in two dimensions - by topic and by layer. It allows us to structure a program in services or direct use of objects. There is a slight deviation from true OOP in that things can get a bit procedural or perhaps functional in style. However, given proper management of concerns this may not be detrimental.



Thursday, May 7, 2015

The Three Amigos

The Three Amigos refers to the lead developer, qa analyst, and business representative reviewing and elaborating the requirements. They should be taking the business requirements and turning them into real acceptance criteria. That acceptance criteria should then be used to drive testing at all levels.


Hopefully, the acceptance criteria is written in a way that can be directly translated into tests. One technique that can be used is to write the acceptance criteria using a Given-When-Then syntax. Given is the precondition, When is the action, Then is the result after the action is complete.


Mockups and screenshots are a great way to provide some high level detail about the change. Where it falls short is in really shaking out the details, providing specifics, and defining behaviors for edge cases.

What we do, and why we do it.

Generally speaking, we development teams will tend to have several "environments" that we deploy changes to before going live with a particular change set. An ideal minimum is four environments including databases, web servers, and other resources that apps interact with. Some resources might not be completely isolated if it adds no value.


First, we deploy to a pseudo-environment - local. Local is for integration testing our own work in isolation.


Dev is typically the first environment we deploy to. Sometimes its nightly or CI. Here we ensure that things are building once checked in and mingled with other code. We run automated tests here and perhaps have some gate process.


When its ready for testers to mash away at it, we promote to QA or TEST environment. Here is where our testers bang on the code to make sure it works and that we're delivering on our promises.


Once the release is ready to ship, we will move it to UAT/STAGE. This environment serves 2 purposes - it gives the stakeholders a place to have a look before go-live but more importantly, this is how we validate our deployment plan. We may have a number of changes that need to happen, but applied those in phases to QA. This is our chance to shake out any issues that we may encounter when deploying to a stable environment that matches prod.


Then we go live to PROD.


When something fails after we go live, we typically scramble wondering what happened. It passed QA so how does this not work in PROD!? When this has happened to me, it's often been a release that never went through that so important pre-live deployment. There are various excuses we have for skipping STAGE, all of them useless because we know better.


One excuse I've had is that we don't have a STAGE for this app. I could've used some foresight and built it. Or in the case where it would mean an extra license, I could stage in the DR environment where we do have a license.


Bottom line is that we need to deploy to STAGE so that we know we can deploy when we do go live, no more excuses.