2100 Solutions – NEW Ruby on Rails website NOW in production on Heroku

After a few embarassing announcements, and failed launches, I have successfully re-crafted my website2100solutionsLogofor 2100 Solutions Consulting, LLC.   This branding of my services includes, Program Management, BPM Strategy, Quality Assurance, Testing, Performance Preparation and Strategy, Automated Testing and Product Development.

Here is a URL for the Ruby on Rails website I just launched using the Heroku enviornment this weekend.  http://2100solutions.com

Heroku was by far the easiest host to implement.

Now a stable 24/7 presence with links to my external blogs and pursuits.

I have other RoR websites completed, but not yet launched on Heroku.   All published websites will be managed through GitHub.  My account at GitHub is WAFulbright, if you’d like to see or follow or contribute to my code!  Let’s do talk before you contribute!   Thanks!

Bill Fulbright


14 Factors Slowing Your Website & How to Handle Them

Techno Functional Consultant at HighRadius


“250 milliseconds, either slower or faster, is close to the magic number for competitive advantage on the Web” – Harry Shum, Executive Vice President of Technology and Research, Microsoft.

According to a report published by the site optimization website Strangeloop (now Radware), 57% of online customers will abandon a website after waiting 3 seconds for a website to load out of which 80% will not return ever again and half of this fraction will tell others about their bad experience. Add to this the fact that Internet users are reported to have faulty perceptions of time spent ‘waiting’ (15% slower than actual load time), we can imagine how crucial role Web Performance (Speed , Stability and Availability) plays in determining the success or failure of an enterprise in this exceedingly online world as it directly impacts user retention , online feedback, number of downloads (mobile apps) , conversions, and thus, revenue.

The quantitative rewards of having a fairly fast and robust online presence can be imagined by the fact that President Obama’s fundraising site raised an additional $34 million for his campaign in 2011, after increasing page speed by 60% and that Intuit saw a 14% increase in conversions after cutting down its load time to half (Ref.). On the contrary, any adverse behavior brings with it the cost of lost opportunity, potential loss of customer loyalty and a severe damage to the brand reputation.

An ideal way to mitigate such risks will be to estimate the impact of web performance and downtime on the business revenue using production load statistics juxtaposed with business revenue model and use the findings to optimize the capacity planning process and appropriate funding for performance tuning/testing activities accordingly.

Large enterprises mostly have dedicated teams to avert any ‘slowness’ in production , armed with state of art 24 X 7 real time monitoring and diagnostic tools equipped with dashboards and alerts/triggers , self-healing mechanisms, graceful fail-overs (like Oracle RAC implementation) and multiple levels of redundancy and data backups to take over the primary configuration in case things go south.

The precursor to such monitoring and arguably a much more vital step is to test this chunk of code and all the pieces of production hardware where this is going to be deployed for predefined performance goals w.r.t throughput and latency through a battery of tests (load, stress, scalability, soak) usually performed by a dedicated Performance Testing and Engineering Team (or the development team itself) over a period of time before release. Since prevention is always better than cure, almost 90% of  performance issues in production can be prevented if the hardware, configurations and code are thoroughly tested together by performance experts and the results carefully analyzed (avoiding wrongful extrapolations) for any anomalies and deviation from the standard expected behavior agreed upon by all the stakeholders.

Easier said than done, there are a plethora of challenges that the Performance Engineering team usually faces in this process , the most important ones being the absence of a 100% mirror environment of production (due to cost constraints), lack of enough unique test data for applications under heavy load (in tune of millions of hits per hour), stubbing or virtualization of test data in absence of enough unique test data (which fails to simulate exact production like realistic loads) and lastly the common practice of selectively targeting only business critical and high volume business flows for load and stress testing due to time constraints while neglecting other business flows which become potential threats as they can trigger a slowdown and an eventual crash over a time period by a simple memory leak or unexpected load behavior.

How the end user perceives the application/website performance will depend on a host of factors like the end device being used for access, network speed in that geographic location, code behavior and hardware capacity at different levels (back end, middle ware and front end), the overall user load at that point of time and a multitude of configuration settings (like thread pool configuration, message queue lengths etc) at the application, database and web servers.

A Performance Engineer in true sense has the responsibility of tuning all these components and configuration settings within them so that working together they deliver peak performance and do so at the minimum cost, almost with the precision of conducting a 1000 pieces symphony orchestra. Though, this might sound overwhelming at first and admittedly takes years to master, the Performance Experts know by experience that most of these performance issues can be usually attributed to a few broad areas and  improperly configured parameters which might have gone unnoticed or were overlooked by the developer and tester during normal development cycle.

The remaining part of this article is a non-exhaustive list of such probable problem areas and configurations to inspect when facing a performance degradation. In a holistic way agnostic to any specific technology, database or middle ware/web server (but mostly revolving around Java Enterprise implementations), the list is based on my personal experiences in similar roles and also talks about detecting and resolving the related performance issues using appropriate tools and methodology, assuming basic understanding of performance engineering related terms and concepts by the reader. This can also be used in parts as a high level checklist by a Performance Engineer to refer to before finally stamping the code and hardware configuration fit to go live.

  1.  Memory Leaks: Memory leaks are one of the most common reasons causing slow response times over time in a Java Code, arising out of improper JVM configurations and malicious objects. If left unchecked, such leaks can cause a complete shutdown (OutofMemory error). There are multiple ways to check for memory leaks as per tool and time availability like interpreting the output of  -XX:+PrintGCDetails on the console directly or monitoring GC behavior on Introscope (saw-tooth pattern). For digging deeper, taking heap dumps (jmap) and analyzing them on tools like IBM PMAT or Eclipse MAT plugin can give an in-depth information on the classes and objects causing the leak. Memory leaks can be resolved by handling the discovered classes/objects at code-level by the developer and tuning the MemArgs Settings for the JVM.  JVM Tuning is an extensive topic in itself requiring a through understanding of memory management in Java and beyond the scope of this article but on a high level involves using the most suited GC algortihms for minor and major GC  along with setting optimum values of Xmx, Xms, Survivor Ratio, NewSize and MaxTenuringThreshold parameters as per the expected allocation rate. It is a common practice to test different JVM configuration settings for the same load and select the one giving best performance at the end. One can refer to this wonderful guide for in-depth information on JVM tuning for best performance. Tools: JMX Clients (JConsole, JVisualVM), JStat (Command line tool), GCViewer, HP JMeter, Introscope LeakHunter, Profilers (hprof, AProf).
  2. Thread Blocks & Deadlocks: Abnormally high CPU usage, requests getting timed out and abysmally slow processing can be caused by thread blocks (one thread occupying the lock and preventing others from obtaining it) , deadlocks (thread A needs thread B’s lock to continue its task while thread B needs thread A’s lock to continue at the same time) or waiting threads at the CPU level. Best way to identify and fix a thread issue is to take thread dumps (also known as Java Dumps) at frequent intervals (jstack utility) and analyzing them using tools like TDA (Thread Dump Analyzer) to check the number of blocked threads, waiting threads or a potential deadlock pattern (such pattern finding can be done manually too but tools make life easier). getThreadInfo returns information difficult to acquire by thread dumps like the amount of time that the threads waited or were blocked along with a list of threads that have been inactive for abnormally long time-periods. Tools: Thread Dump Analyzer, Introscope (can take thread dumps directly), Samurai (open source), JConsole.
  3.  Gridlocks: Too much of synchronization to avoid thread deadlocks might inadvertently ‘single-thread’ the application. It can lead to very slow response times coupled with low CPU utilization as each of the threads reach the synchronized code and enter a waiting state. This can be confirmed by checking thread dumps for a large number of threads in wait state (Waiting or Timed Waiting) across multiple dumps taken consecutively. Gridlocks can be avoided by trying to use immutable resources and using synchronization sparingly, at the code level.
  4. Thread Pool Size:  In web applications thread pool size determines the number of concurrent requests that can be handled at any given time. A properly sized thread pool allows as many requests to run as the hardware and application can support without straining the hardware. A larger than optimum thread pool leads to unnecessary overhead on the CPU which can further slowdown the response while a smaller than optimum pool size will lead to lot of threads waiting for execution, thus again slowing down transactions. An ideal way for determining the pool size is to estimate the average number of users in the system using Little’s Law (average serving time multiplied by arrival rate) and size the thread pool to match this number (keeping buffer for occasional spikes) while also ensuring that this size is ably supported by the hardware (i.e. number of CPUs at disposal). If there is a sudden increase in user load (more than the expected spikes) or even a gradual growth over time (for example with increasing customer base), the thread pool size needs to be realigned accordingly for the response to be equally fast as earlier.
  5. Database Connection Pool Configuration: Database connections are relatively expensive to create. Hence they are created beforehand and used whenever access to database is needed. This also limits the amount of load coming from a particular application to the database as too much of load can crash the database and impact other applications (in case of a shared database). This pool size has to be optimized according to the load expected and hardware capacity of the database server. As is the case with thread pools, a small DB Connection pool will force the business transactions to wait for a connection to be available. This can be confirmed by monitoring the queue time and length , both of which will be increasing rapidly. Also, majority of the business transactions will wait on aDatasource.GetConnection () call while Database will show low resource utilization.  On the contrary a very large (larger than optimum) pool size will allow too much load to flow to the database and can slowdown business transactions across all application servers accessing this database. This is characterized by high SQL query processing time and high CPU utilization on the database, observed from DB logs or AWR Reports. The application will wait on DB query executions (PreparedStatement.Execute()). The golden value for pool size is just below the saturation point in general.
  6. Poor/Corrupt Table Indexes:  This is a very common cause for SQL queries taking a long time to process. Once we have the query causing the slowness identified (by say AWR report or db logs) we need to list out all the tables being called in that query and check for indexes on all those tables. More often than not, if the query has shown a sudden degradation in performance and the query in itself has not been modified , it can be fixed simply by rectifying/rebuilding the faulty indexes.
  7.  Badly Designed Stored Procedures/SQL Queries: Many times the existing Stored Procedures are modified (making calls to new tables, new join statements etc) to support new functionalities. If there is a noticeable degradation in query processing time when compared to a previous codebase, these modified procedures need to be checked as first suspects. It is very possible that some performance impacting bit has crept in the query (increased number of sortings or full table scans) which is causing such behavior. There are multiple query optimization tools available in the market like DBOptimizer by Idera, SQLSentry PlanExplorer, queryProfiler by DBForgeStudio etc but the best way to get around such issues is to get hold of a DB expert (if you are not one) and let him/her tune the query !
  8. Non-effective bundling / Excessive http requests: While testing front-end systems, if there is observed a degradation in page load times at the browser, one of the easiest ways to do root cause analysis is to observe the Network tab in Developer view on Chrome browser while keeping the page under inspection open. This not only lists all the objects (like stylesheets,  images etc) being downloaded with their size and total count but also the time taken by the browser to download each of them. This list can be sorted for maximum time consuming objects or object size and then compared with the older code base before degradation (if available) for the number of components being downloaded and their respective load times to pinpoint the cause. An increased number of components getting downloaded (without any change in functionality) will require more number of http(s) requests adding to the page load times and indicating non-effective bundling/packaging of objects which need to be fixed at the code level. For a long running test, we can use the Web Page Diagnostics tool offered by HP Loadrunner to get similar metrics on component level response times for a webpage.
  9. Faulty Methods in Specific Transactions:  If there are specific transactions in test or production which appear to be problematic w.r.t. response times, we can trace their execution paths and component response times using Introscope Transaction Tracer. Transaction tracer not only filters poorly performing transactions based on given filters but also helps to identify the cause (components) causing such behavior within those transactions. Introscope also provides the provision of Dynamic Instrumentation on the fly (attaching byte code to return more metrics from a particular method selected for deeper investigation). The identified components need to be isolated and fixed (mostly at code level) in order to get things back to normal.
  10. Poor load distribution / Improper F5 Configuration: Load balancers are used for increasing the concurrency and reliability of large systems (by redundancy) but if  they do not have enough resources or are not configured properly (for example incorrect weights assigned in Weighted Round Robin (WRR) or Weighted Least Connection (WLC) algorithms), they can actually decrease the performance of application by putting too much traffic on a single server in the cluster or acting as single point of failures.  Load balancing issue leads to unequal distribution of load across servers and the same can be easily confirmed by monitoring CPU  usage, memory utilization and logging activity on all the servers sharing the load w.r.t. each other (the instances not taking load will be in ideal state). This overload of traffic on the remaining servers if left unchecked can cause severe performance degradation and might eventually lead to a crash because of not enough hardware available to handle the excess load. Apart from the load balancer configuration, such a behavior can also be caused by all the server instances not coming up properly to take up the load after a restart or new code deployment/ configuration change.
  11. Too Many Context Switches:  A high context-switching rate  (switching of CPU from one thread to another) indicates an excess of threads competing for the processors on the system. Context switching is a computationally intensive task and an unusually high switching rate will adversely impact the performance of multiprocessor computers. Excessive switching can be caused by excessive page faults caused by insufficient memory or a processor bottleneck w.r.t load . This can be monitored using sar -w and proc/[pid]/status on the server or by enablingRSTATD on the server being tested and observing the metric ‘Context switch rate’ in LoadRunner. Context switching rate can be checked by reducing the number of active threads on the system by the use of thread pooling or disabling hyper-threading if enabled.  The ultimate solution is to bring in a more powerful processor  or simply adding an additional one to the existing.
  12. JDBC Connection Leaks:  Connection leaks happen when we open a connection to the database from our application and forget to close it, or for some reasons it doesn’t get closed by the code. Connection leaks saturate the connection pool for new connections to be established causing major timeout and slowdown issues. Such leaks can be investigated by analyzing thread dumps for total number of created, active and idle threads or monitoring JDBC pool utilization using Introscope. Once confirmed, there are multiple ways of resolving this issue based on the implementation. For example using Weblogic Profile Connection Leak mechanism to pinpoint the root cause,  using Spring JDBC templates or using connection pool implementations which offer the option of forcefully closing connections (or notify about connection leakage) based on predefined conditions (the TomCat connection pool has logAbandoned and suspectTimeout properties to configure pool to log about possible leak suspects).
  13. Saturated Message Queues (MQs): A much larger than expected load can saturate the message queues and cause timeouts at the application level. If there is a message queue implementation in place and a slowdown is observed beyond a particular load during testing, it is a good idea to check the queues for saturation and flush them (in test) if saturated. Queue lengths can be monitored using Sitescope or by logging into the MQ servers. In case of  repeated saturation, the queues need to be optimally reconfigured as very large queue lengths can also cause a slowdown by hogging too much of memory. Relevant attributes to configure is Max queue depth in IBM Websphere MQ.
  14. Saturated Disk Space by excessive logging: As trivial as it might sound, it is quite a possibility that the disk space gets saturated earlier than expected (on account of some recurring error making the logs grow 100 times faster than usual or an inadvertent change in logging mode to error/debug from info) causing the response times to slow down before starving and the server thus refusing to process any further requests. With hundreds of metrics to monitor and inspect, this is also one area which tends to be easily overlooked at times. Disk  space utilization can be checked using du/df commands or monitored through Sitescope in real time. Once detected, we need to figure out the cause (look for errors and logging mode), fix it, clean up the disk space (or take backup) and then start all over again.

In addition to the problem areas listed above, it is a good idea to keep an eye on the Stall Count metric on Introscope where consistently high values imply slow backend, periodically high values imply load related bottlenecks in the system and progressively increasing count implies resource leaks. For more advanced diagnostics, custom Probe Build Directories (PBDs) can be written and deployed and the preferred metrics thus configured can be monitored via Introscope graphically. 


  1. http://javaeesupportpatterns.blogspot.in/2011/02/jdbc-pool-leak-using-weblogic-90.html
  2. http://businesswireindia.com/news/news-details/wily-technology-introduces-new-tools-introscope-transaction-tracer-int/2491
  3. https://plumbr.eu/blog/io/acquiring-jdbc-connections-what-can-possibly-go-wrong
  4. https://docops.ca.com/ca-apm/9-6/en/using/ca-apm-metrics/the-five-basic-metrics#TheFiveBasicMetrics-StallCount



So many of these people who lost their jobs are the victims of a poor economy or a struggling company or both. They are capable and hardworking, and their unemployment is not due to their lack of effort or desire.

Some people, however, lose their jobs due to factors they could control. I recently polled a number of leaders and asked them to tell me the top reason or reasons people lost jobs in their organizations. I asked them not to include those whose jobs were eliminated due to economic or financial reasons of the company. I was able to group their responses into ten categories. Although my poll is not scientifically validated, I think it is nevertheless instructive. Below are ten responses, listed in order of frequency, and realizing that there is some overlap in the categories.

  1. Failure to keep current in their field. “Rapid change” has almost become cliché. One leader said he had to dismiss some people who were acting like it was still 2007. In other words, if you haven’t kept current or updated your skill set in the past five years, you are incredibly behind your coworkers. Other leaders said they expect their employees to reinvent themselves regularly.
  2. Poor relational skills. Those deficiencies include an inability to work well with others, poor self-awareness, and a self-centered attitude. I note the latter issue separately below because it was mentioned frequently. One leader told me that he let go of two of his smartest employees because their attitudes were toxic to the organization.
  3. Moral failure. I expected this response to be near the top and it was. Some of the most promising workers have been fired for actions that could only be described as stupid.
  4. Failure to carry out assignments. Some of the leaders expressed amazement at the number of people who failed to carry out an assignment and offered no explanation why they failed to do so. “One former leader on my team,” a CEO told me, “ignored my assignment for months without explanation. I guess he thought that the task would just go away.”
  5. Failure to take initiative. Some of those who responded to me were leaders in mid-size to large organizations. Their direct reports were brought into the organization with the expectation that they would be highly motivated workers. But when they failed to take initiative, their value to the organization diminished. “I need people who can come up with ideas and strategies on their own,” one leader said. “I don’t need to be giving them assignments with specific instructions every time.”
  6. Negative talk. Some people lost their jobs because they were the sources or carriers of rumors. Some were incessant complainers. And even others were simply negative people. Their dispositions and conversations made the workplace unpleasant and discouraging for others.
  7. Laziness. “Most lazy workers do not realize that everyone in the organization knows they are lazy,” a midlevel leader told me. “You can’t hide poor work hours and poor work ethic from others. I have to deal with lazy people in my division before that attitude permeates the entire division.”
  8. Attitude of entitlement. We did go through an era in America’s employment history where adequate work and sufficient tenure guaranteed some employees a lifetime job, benefits, and retirement. That era exists no more. Those who still have an attitude of entitlement may soon find themselves on the sidelines of employment.
  9. Failure to demonstrate productivity. Workers in organizations should regularly ask if they are being treated fairly for the work they do. If not, they should pursue other options. Workers can likewise be certain that now, more than ever, they are being evaluated in the same manner. Are they productive? Do they truly “earn their keep?”
  10. Self-centered attitude. More and more workers are evaluated by their attitude as well as their direct work. Are they team players? Or do they always and obviously act in their own self-interest? Do they demonstrate humility? Or do they demonstrate hubris?

The workplace is changing. In many ways, all of us are more free agents than career workers. We have to demonstrate our worth each day. Those who do so will have many options before them. But those who don’t may find themselves in the ranks of the unemployed.

What do you think of this list? What would you add, delete, or rank differently?

2100 Solutions launches NEW Cloud Based, Ruby on Rails website!

Here is a URL for a Ruby on Rails website I just launched using the Godaddy Cloud Server today:

I have tried AWS, Open Shift, Dreamhost, etc. Godaddy was the easiest.

The IP:port still needs to be updated so that the Domain Name for 2100Solutions.com appears.

One last little piece of magic left to go….but I couldn’t wait to show it…

Ruby, Ruby On Rails, SQLite3, RVM, rbenv, bundler, all source code, launched from the command prompt @ Godaddy VPS and it all works.

A new Ruby App – Salary Bonus Calculator

Here is an app I just made called the “Salary Bonus Calculator”.

It is very short, but powerful, as it not only demonstrates it’s usefulness, but has room for much more development, which is coming.

I have embedded the video which is published on my Vimeo site.

Salary Bonus Calculator – Ruby App from Bill Fulbright on Vimeo.

Key Needs for most Data Management Project

Thoughts and Key Strategies for Test Data Management:

Data Acquisition

  • Data Profiling and Distribution
    • Data that includes confidential or sensitive information can still be shared, however. There are a number of steps researchers can take to protect subjects’ privacy2:
      • withholding part of the data
      • statistically altering the data in ways that will not compromise secondary analyses
      • requiring engineers who seek data to commit to protect privacy and confidentiality
      • providing data access in a controlled site, sometimes referred to as a data enclave.
  • How is it provided
    • The data have its own device name and data name. The data is stored in a separate file with binary format. Each file has “n” number of columns for data, which generally represent various data features.
    • from stored historical data
    • Active systems / projects
      • from dynamic / fresh data
    • Web site/platforms
    • Mobile / OTA
  • Automated, Tool or Manual Data Preparation
    • Automated Accelerators
    • Tools such as Informatica, etc.
    • Manual teams – most used – and can be up to 40-50% of the project spend
    • defining test data
      • to be used in a test case,
      • copying or creating test data,
      • securing or masking sensitive data,
      • and so on—are taking up more than half a developers’ and QA team’s time during the testing phase.
  • Data Integrity
    • Data must be archived in a controlled, secure environment in a way that safeguards the primary data, observations, or recordings.
    • The archive must be accessible by engineers analyzing the data, and available to collaborators or others who have rights of access
    • Primary data should be stored securely for sufficient time following publication, analysis, or termination of the project.
    • The number of years that data should be retained varies from field to field and may depend on the nature of the data and the research.
    • Keeping data partitioned and limited to view by assigned groups
  • Data Maintenance and Refresh
    • When determining the appropriate storage format for  data, consider
      • What will you do with your data once you acquire it?
      • Will you write and read data with the same application?
      • How much data will you acquire?
      • At what rate will you acquire data?
      • Will you need to exchange data with another program?
      • Will you need to search your data files?
  • Data Governance
    • Rules and Policies for testing phases and teams
    • How is it used

Without Test Data Management

Define Test Data Requirements

  • Tester Efficiency
    • Cost Per Test Cycle = $2.7M
    • 100 Days, 300 Testers, $90/hour
    • 20% application defects due to bad test data
  • Application quality
    • Cost of a defect found later in the release cycle = XX

With TDM

Define Test Data Requirements

  • Improve Tester Efficiency by 30%                                         Improve Tester Efficiency by > 30%
    • Cost Per Test Cycle = $1.6M                                           Reduce Testing cycles by > 25%
    • 60 Days, 300 Testers, $90/hour                                       Improve application quality by 90% Tester Efficiency
    • 90% reduction in test data-related defects
    • Cost avoidance

ref: Informatica “Why Do You Need Test Data Management?” 
ref: Forrester Report:  “http://tealium.com/assets/pdf/Forrester_Boost_Digital_Intelligence.pdf

Remote Freelancing

I started my career, working without at net. Full commission insurance sales with my family’s business. Scary. The good part was that my father believed I should get into as much debt as possible as an incentive. Heh. No kidding.

However, he was one of the most successful salesmen I ever met (in many ways). He taught me two really important things: how to prospect, and how to follow up. If you can do that, you will be successful at anything. Now you have to understand what those two simple things mean….

  • Prospecting =
    • Cold Calling
      • Phone calls to expired insurance policy holders
      • Walking into a business “cold” and asking to speak to the owner.
    • Looking for new or closed businesses as you drive around, taking notes
    • Looking at commercial trucks to see if they are maintained well and clean, taking notes
    • Who do you know, what do they do?
    • Can you help them by looking at their present insurance?
    • Can you do a better job that what you found?
    • Can you out price the other policies?  If you can’t, can you sell service?
  • Follow Up
    • Keep your word – Do what you promised to do
    • Provided Customer Service that leaves “not a penny on the table”
      • the customer will be so satisfied, he will never go anywhere else
    • Remember important facts and details to provide stellar Customer Service
    • Earn your customer’s business with service
    • Be honest

No, this is not an insurance course, but it is one of the foundations that I feel makes a person successful at anything.  No, you don’t have to do it exactly like this.  But these are good to know.   If one plans to be on their own and freelance, this would be a great framework to learn.  Can you see how this would be of value?  Has anyone ever laid this out for you?

Oh, one more thing, one of my dad’s friends (and clients) invited me up to his office one day.  This was before computers.  Yes, I am still alive!  He taught me about his “treasure chest”.  Let me explain what kind of guy this was.   He was the son of a man who built a moderately successful chain of appliance stores.  He leveraged his dad’s few stores into a multi-state empire, which ultimately went public.  Have I gotten your attention?

The treasure chest was a metal box large enough to hold a set of 3 x 5 index cards, and a set of 3 x 5 index cards with daily dividers for the month.  He said this was his secret to success.  Well, it was more than that, but it was the principle.   Each day, he would go to the date for that day, and look to see what index card he placed in it for that date.  He would do what ever it took to give that prospect, customer, or issue the best customer service and make a sale.  What ever it took.   This was a CEO who walked the floors, visited his properties, solved problems on the spot, took care of his employees (including paying for them to go into rehab).  He EARNED his way into everyone’s heart.  What did he get back?  LOYALTY.

This one word is the fruit of all these ‘tricks’ of the trade.   I have used them in several careers, including the last 19 years in the IT / QA business.  I have  been independent Contractor, Full Time Employee, but not yet a “FREELANCER”.  Why?  I guess I didn’t feel my network was strong enough.

Enter TopTal Software Development group.  I just signed up yesterday.  Why?  I am on the market, trying to do things the “old” way.   I found that TopTal has a structure, a framework, and a network – different than all the recruiters in the world.   I am writing this to show that I FULLY APPRECIATE what it took to build such a company, filled with loyal, inspired, talented and gifted creators and artists in the technical trades.   I also am making a transition out of quasi-technical coding into pure language coding.  No crutches.   I only need to be with a group that is willing to share with me if I need it.  I will do my part.

So, not only has Toptal Software Development group challenged me to write an article that features them, I am challenging them to show me as well what kind of company they are.   I am betting they will exceed my expectations.

About me?  I was in insurance for 9 yrs with my family, 8 years full time Professional Entertainer, helped to build two booking agencies, started and built a management consulting firm for 12 years, became a Sr. V.P. of Operations for a Mortgage Company, and finally struck out on my own as a grunt tester 19 yrs ago, with the express goal of working my way up from the bottom to learn the industry.  I have been a tester, Lead, Manager, Sr. Manager, Practice Head, Trainer, Offshore leader, Delivery Manager, BA, system analyst.  I learned the Credit Card and Insurance back end systems for CITI, JPMC, BoA, Home Depot, AIG, CNA, Zurich, Bank of Montreal, President’s Financial, Fireman’s Fund, and survived the big 5 consulting machines.  My last contract was as a Sr. Business Architect using Mulesoft API Designer, Kibana, Elastisearch, Cloud hosting, PHPStorm, Ruby, Cucumber, JSON, Jenkins, and so on to reverse engineer a legacy platform driven by a hard coded front end with PHP, into an extensible framework of RESTful API and Microservices delivering as part of a Java middleware to the unchanged database.

I was a music major in college.   I learned all this on the fly, and because I wanted to.   Now I am retooling again, and plan to be more successful than ever.  I am betting on Toptal!

Have you ever noticed…. | Bill Fulbright | LinkedIn


Boy, Have I EVER!!  Just when it is time for production – erk.  there it is.  How could we have missed it?

A missing requirement?  A sneaky service with a bad gate issue?  An API with one of it’s Camels out of case?  What — a profile permission got changed?

I know you know.

So that’s why when people ask me what I do, I say “I look for what isn’t there…” or  “I think backwards”, or “I ask the stupid questions”.  Heh.  Right?  So much in a system can bounce or jiggle until we literally remove all exceptions.

But how can that be done without a seasoned QA approach?  When there is an abundance of  ‘rabid deployment’, splinter releases, and .2.b releases, mistakes are bound to happen.  Simple stuff.  But overlooked stuff.  Snags that cause delays.

Today in Agile approaches, I have thankfully seen automation turn these things up quickly before a sprint is done, and wham-bam, it is done and fixed.  So much can be done now to remove the human error, but how much of the behavioral testing gets pushed to the side?   I, to this day, still hear.. “Oh, we don’t use automated Unit test tools”.  I say, “Oh, really?”  Then, I might hear, “Yeah, we just do it manually”.  My thought bubble says, “hmmm”.  I can take an automated unit test tool and build it into a stack of tests, scenarios and e2e tests running critical path workflows.  But if the unit test fails, it all crumbles.   What happens if (God forbid) the code must be regression tested?  Manually?  Really?  Sigh.

All I am saying, which is old news, but still fun to expose, is that there are simple ways to think things through to help make the system more bullet proof.   I kinda like the idea of stacking up a series of small tests into a test case, then into a scenario based upon a workflow.  If that works, geez, we can get fancy.  Jus’ sayin’.  Fun with testing, right?  But will the budget allow it? erk.

Source: Have you ever noticed…. | Bill Fulbright | LinkedIn


NOTICE:  The SDET FOUNDRY MEETUP will be on Thursday, Sept. 3, 2015 @ Panera Bread Company on Windward Pkwy, Alpharetta, 30004.  7:00 PM.   Normally the first Thursday of the month.

Anyone who is an SDET resource, or who is learning the ropes to become one! We will be discussing RESTful API development, interfaces, RAMLs, WEB Development, Ruby, Cucumber – from a theory, learning and application approach. Bring your GAME!




See you there!  Bill