The subject of his presentation will be “A Protracted Descent into Madness with Kris Kowal. BYOC”. This presentation is appropriate for all skill levels, and discussion is welcomed!
The Meetup will be Thursday, 7:00 pm November 7th, at ITAC’s Vestavia Office. Please join us for a unique opportunity to “swap development war stories”, learn bleeding edge development tactics and network with some of the brightest minds in Birmingham’s IT community. Food and beverages will be provided. For additional details, please contact Nathan Stott, firstname.lastname@example.org.
Kris according to Kris:
Registration is encouraged, not required. http://www.meetup.com/bhm-js/
Free of Charge
We all have our secrets. Some we would share, and some we place under lock and key, and it is usually with only our closest ally that we disclose those precious details in hopes of preserving our reputations and even our lives. Notice I don’t say ‘friends,’ because while I have some wonderful friends, some of them can’t keep a secret to save their own lives much less mine. Continue reading…
The healthcare industry is in a mad rush to get up to digital speeds and to become relevant in the new world of ObamaCare. The impetuousness came with ARRA (American Recovery and Reinvestment Act of 2009), when the federal government offered to pay medical practices and hospitals the money to upgrade their Health information technology (health IT) if they qualify under Meaningful Use (MU). It is an investment our government is making that should also provide a healthy return.
The United States spent more on health care per capita ($7,146), and more on health care as percentage of its GDP (15.2%), than any other nation in 2008 and in December 2011, the outgoing Administrator of the Centers for Medicare & Medicaid Services, Dr. Donald Berwick, asserted that 20% to 30% of health care spending is waste. This waste comes in the form of over-treatment, failure to coordinate care, administrative complexity, burdensome rules and fraud. So with the government making such an admission, it means they are desperate to see a more efficient system, where tax dollars are no longer lost in the shuffle.
The waste they hope to dispel comes in the form of proactive efficiencies that will help providers reap benefits beyond getting money for an upgrade; reducing errors, increasing the availability of records and data, providing reminders and alerts (making healthcare more proactive), providing clinical decision support, and by automating the process for prescription medication. As redundancies are reduced, costly errors decrease.
What is great about this is that while the Federal government is bankrolling this process, they are not micro managing. This allows the free market inventors to solve the problems in a way that streamlines the process and really works for medical professionals who will be shopping around for the best solution.
To give you some idea of the math involved: ARRA authorizes a net $27 billion in spending to support EHR (electronic health records) adoption through 2017. In perspective, it’s a shadow of what is spent annually on healthcare by the US Government. Medicare, Medicaid, and the Children’s Health Insurance Program (CHIP) – together accounted for 21 percent of the budget in 2011, or $769 billion. Nearly two-thirds of this amount, or $486 billion, went to Medicare, which provides health coverage to around 48 million people who are over the age of 65 or have disabilities. The remainder of this category funds Medicaid and CHIP, which in a typical month in 2011 provided health care or long-term care to about 60 million low-income children, parents, elderly people, and people with disabilities. Both Medicaid and CHIP require matching payments from the states that will also benefit from the stimulus.
If the $27 billion spent on EHR eliminates only 5% of the waste, a conservative amount for the sake of argument, the US Government will save $38.45 billion annually.
Is there a downside? As this data becomes more digitized, privacy advocates are rightly paying attention. But MU requires that the facility “conduct or review a security risk analysis per 45 CFR 164.308(a)(1) and implement updates as necessary and correct identified security deficiencies as part of this analysis.” In other words – they must be compliant with HIPPAA, a topic for another future post
There are always risks with such an overhaul – but the math involved makes an extremely compelling argument in favor of Meaningful Use dollars.
Whiteboard-IT creates custom software for many industries, including the healthcare industry.
When Apple took the world by storm and created the iPhone, it was the device’s simplicity, rather than its complex list of features, that won the day. In technical terms, we call this elimination of unnecessary state; the process of reducing the list of options to eliminate the clutter.
Apple understood this concept, and made brilliant decisions to reduce features in order to give it the friendly factor. You will notice one button instead of 18, one device instead of exposing their iOS to the open market, one place to download apps and music, the latter of which has given them much control profitability.
Consumers rave about the iPhone’s intuitive and user-friendly nature. The reduction of state and good design is what gave it life, allowing only one application at a time with only one physical button. No confusion. Easy. beautiful.
Programming is the same in many ways, with no fewer temptations to add multiple features.
Look what happens if you add one parameter; You are creating a true condition and a false condition. Then add another parameter. Now you have 2^2 or 4 conditions that you will need to test. Add a third and you are at 8 conditions. In this vein, Windows clearly offered many features and services (internet, phone, contact management) but its first phone, with all its working parts, was a bust.
More features = more working parts = more opportunity for clutter or failure. Complex API’s are necessary. Nowhere does this rule hold truer than when you are dealing with vast amounts of working data. In the end, if it is not simple to read or use, it will collect dust.
I have seen many instances where a new piece of software was installed to solve “every” problem a company was having. The challenge? Such solutions are big and scary and often come with a giant learning curve. This is why Basecamp grew so quickly (it solved one big problem), and why Workamajig, a much more complete system, requires so much effort to sell, train, and install, and why they need a one-year contract to get things going. If people don’t invest in the idea, they will not use it. It’s just too hard.
The world of apps is taking off so successfully for the very same reason. Mobile Apps handle one idea, big or small, at a time. So, if you want your launch to be successful, you may want to do a little elimination of unnecessary state on your own. What big idea do you want to solve?
A Programmer’s Haiku
For on-time launches
We admire to dispel
A programmer’s optimism
— Marshall Malone
Experience teaches a developer that the qualities that make great programmers can also break them.
Programmers are artists. Programming is a synthetic art. Programmers create something from nothing. Therefore, it is not a stretch to say that a programmer, by nature, is an optimist.
The difficulty, however, is that a programmer’s belief in himself, or a project’s outcome, does not always allow him to factor sound logic in his construction of a timeline. When this happens, his optimism has failed him and the client. Most programmers will admit that they consistently underestimate how long it will take them to accomplish a task.
I’m inspired by the book; The Mythical Man-Month, by Frederick Brooks, Jr.; a well-known IBM developer. At the book’s core, he dispels the notion that adding man-hours to a project will speed the pace of that project. In fact, he affirms “adding manpower to a late project makes it later.” In describing this assertion, he uses the analogy that 9 women cannot work together to produce a baby in one month.
The Man-Month, in a timeline, suggests that X number of men can accomplish Y many tasks in Z many months and that the men and months are interchangeable. (more men = fewer months, more months = fewer men, etc…) As eager as programmers and patrons are to see a project to conclusion, many employ this myth into their logic. This brings a slow and painful death to their client’s satisfaction.
Brooks says, “Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.” In other words; when tasks require heavy communication, the project doesn’t speed up with more effort. In fact, adding man-hours can slow a project down.
I remember a client’s story; how 2/3 of their team was replaced with “better developers” in the middle of the project. Though the developer believed and even insisted they would be on time, his reasoning was based on a false and optimistic notion; the mythical man-month. As the client feared, they launched almost 6-months later than intended, and by the end of the 6th month, everyone was seeing blood.
At the root of this is the understanding that programmers don’t just slip into a project. They require training by those people who are experienced in the project. For example; adding 2 men will require at least 3 man-months to get them up to speed; time, which is most likely, not budgeted in the original estimate. This also means the tasks are redistributed 5-ways so that by the end of the 3rd month, 7 more months of effort remain. With 5-trained people standing; only 1-month remains in the budget and the product is now late, as if no one had been added.
To hope to get done in 4-months, considering only training time and not repartitioning and extra systems test, would require adding 4 men, not 2, at the end of the 2nd month. Now, one has at least a 7-man team, not a 3-man [team]…”
And the client suffers as their expectations far exceed the reality. There are two prices that every client pays when a project falls behind.
- The financial and psychological costs to both developer and patron because of added man-hours.
- The impact of late software on a business, which depends on the project to support the business efforts.
As costly as this is, it is a failure by most developers to deploy sound planning principles. Instead of calculating myths, the average project should look like this, according to Brooks:
1/4 component test and early system test
1/4 system test, all components in hand
- The number of months of a project depends on its sequential restraints.
- The maximum number of men depends on the independent number of subtasks.
From these two quantities one can derive schedules using fewer men and more months. One cannot get a workable schedule using more men and fewer months.
Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I think of our company as one that provides reliable service, but I have been recently affirmed in this notion when I began reaching out through social media. The results blew me away.
This summer we launched a new initiative to reach out to our personal connections and see whom we know. It wasn’t a difficult exercise, but required that we take a bit of time each day to engage ourselves on LinkedIn. When we began, our combined list of contacts was small, more indicative of our social networking inactivity than the reality of connections.
As we reached out, we did not merely send out invitations to connect and move on, but we relied on thoughtful engagement, going for as much quality as quantity. Our hope was to connect in a more tangible way; making referrals, endorsements, writing recommendations, and providing readable and relevant content on our website. It was important to us that this experience was less about intrusion for numbers sake and more about benefitting those with whom we connected. In other words; if they benefitted – it would be returned to us.
It didn’t take long to see an impact on our bottom line. New connections led to new conversations, which led to new projects. In short order, we nearly doubled the number of people in our network, and the connections we made gave us a great deal of positive feedback. Here’s one such example:
Whiteboard-IT is extremely knowledgeable, providing innovative IT solutions to help resolve my needs in a timely and cost effective manner. They are available at a moment’s notice and are highly responsive to issues that need to be resolved quickly. Bottom line…they do what they say they will do. I have recommended Whiteboard to other colleagues in a variety of businesses and will continue to do so. I cannot say enough good things about their customer service, technical expertise, and business personality.
Jessica Boroff, RN, BSN The Compliance Store
Of course she would not have said these things if we weren’t good at what we do. Her recommendation is now posted on our site, which others will also see. But the renewed activity, including these testimonials, has been a priceless part in priming our sales pipeline. And future clients are more confident when they you have mutual connections.
But it goes to show; If you do a quality work at your trade it’s unlikely that everything has completely dried up, fiscal cliff or not. You may find, as we did, that reaching out out to your connections may be of great benefit. It may also generate a nice return.
CFO’s and business owners want feedback from their programmers, which is tough when often times the better programmers have spent their lives incubating skills that borrow from their ability to return phone calls. And costs for a web site are all over the place; from several hundred dollars for a simple revision to a hundreds of thousands of dollars for a site with vast databases, and volumes of functionality. So – when a project depends on a high level of accountability and communication, and all of them do, clients just want to know what is really happening behind the veil of code.
All consultants’ fees are based on a daily billing rate, which reflects the value they place on one day’s labor plus expected overhead expenses. These rates appear in fixed fees, monthly retainers, hourly billing or even by measuring a company’s performance. Either way, those fees must be justified with the quality of their work combined with effective communication and reporting.
The savior of the coding hero is to maintain good internal systems and to enjoy the ability to recognize weakness and to compensate for it by surrounding one’s self with colleagues of varying skills and personalities. This wisdom steers a client away from hiring one-man shops where “man-down” doesn’t mean the death of a project. Consistency comes when redundancies are as present as the front-line programmer.
At Whiteboard, we make a habit of communicating internally through continual education, participation in the open source community and a diligent internal peer review process. In doing so we encourage our staff to pay attention to the details. It also keeps us talking, keeping all parties informed. Upon request, our clients receive online access to reports that monitor the progress of each project, including time sheets.
We have cleaned up many messes created by one-man shops or companies who care little for the details. And while we are grateful for the opportunity to do so, we feel your pain and look forward to providing relief.
You are probably using several software applications that talk to each other. Whether you have a custom web application or prepackaged financial solution, getting applications and services to communicate requires a skill, technique, and knowledge to protect your information. So, what happens when your web service is not secure? What information could you be leaking and how could you be vulnerable?
- Privacy refers to ensuring that messages are not visible to anyone except the web service and the web service consumer. Traffic should be encrypted so that machines in the middle cannot read the messages.
- Message integrity provides a guarantee that the message received has not been tampered with during transmission.
- Authentication provides assurances that the message originates from where it claims it did. Both a legal term as well as a technical term, non-repudiation refers to the concern of not only authenticating a message, but proving the origin of that message to other parties.
- Authorization refers to ensuring that only consumers who should have access to a resource of your web service actually have access to that resource. Authorization requires authentication because without authentication an attacker could pretend to be a highly privileged user.
Building a web service or API (application programming interface) requires a methodology for exchanging secure information, and there are two popular solutions: SOAP and REST.
Simple Object Access Protocol (SOAP) is a popular protocol specification. It is a complicated specification and some developers, though well-meaning, leave security vulnerabilities. An example of a vulnerability is SOAP injection. What is SOAP injection? It occurs when the server attempts to parse the XML message from a client. If the XML message is malformed, meaning that it does not follow the rules that the server expects it to follow, the server may return an error message that actually shows code and gives insight into the underlying system. Developers may turn off this behavior. However, this is often forgotten before a deployment.
REST (Representational State Transfer) is an architectural style for distributed systems. The World Wide Web is one such distributed system. REST has become a popular architectural choice for designing web services. Such web services are referred to as RESTful web services. An advantage of using REST is that the security vulnerabilities are well known as they are the same vulnerabilities that impact web sites. This means that developers who are familiar with website security will be able to leverage their knowledge to secure RESTful web services.
Developers working with either of these technologies must be concerned with the four security points. No methodology or architectural choice ensures that your information is well-protected. It is important that your consultants explain the architecture they plan to use and how their implementation plan accounts for security concerns. If your developer does not have a detailed answer, it is a red flag.
I remember hearing it on the radio; another major retail store was targeted by hackers, a store I had shopped not two weeks prior. That sinking feeling struck, the one that calls me to drop everything in order to familiarize myself with my credit card company’s phone bank to cancel my cards.
New brawny standards protect us against such events and the incentive for a company to comply is tremendous, but tough standards are not great if they are tough to reach. So we ask; is the arsenal guarding us from online theft too hard to grasp for the average online business?
So to answer our initial question; PCI Compliance is too costly for the average businessman to comply, but we are fortunate to live in a free market that sees bureaucracy as an opportunity. Companies like Braintree may have been created with profit in mind, but they are offering a service that gives us carrots and saves us from the stick.
Time entries can help you gain valuable insight into inefficiencies with how time is allocated. However, it’s only as good as the data you have. It’s import that time entries be logged in a way that is meaningful. A detailed comment, is unfortunately not enough. Your time tracking system needs to have the capability to categorize time entries. Without categorization you can’t know the total costs of things.
Think of what information you would like to see during and after the project is over. For example, if you would like to see the following chart.
Then these are the category options that you should have on your time entry system. Every business is different and is concerned with different things. For company A meetings might be a subset of communications. Or it might be important to separate client communication from internal communication. It is important that there are not too many categories. When data is broken down too granular it has a tendancy to lose its meaning. Categories should be different enough and generic enough to quickly and easily choose from when logging time.
The description of what is done during the time should be a single sentence, but enough to point someone in the right direction if more information is needed. After all, we want to utilize the consultant for more programming rather than becoming a court reporter. If more information is needed the time entry comment should be enough to point a resource towards a tag, branch, or issue # for more detail.
If these metrics are important to you then you will need to audit it tightly. Review this at least weekly to make sure that the entries you need are present. If you get to the end of the project and want to know why you are over budget and then realize your consultants have been logging 10 hour days to “Development” or “On Site Support” then it is too late. You can never reclaim that information and any attempts to would produce fictitious results. Knowing where your inefficiencies lay could give you the ammo to ensure that they are improved on the next go round.
Time is a very large part of the equation when working with consultants. So be prepared and figure out what knowledge you want to glean from where they spend their time.
Read the first part in our series. How to get more out of your consultant