Author: jtconsegna

The Power of Coding Standards

Posted on by jtconsegna

While preparing for another AWS Pro cert, I came across an interesting article by Martin Fowler that highlights the cost of cruft. Cruft is badly designed, unnecessarily complicated, or unwanted code.

Having run a lot of software projects in my time and established and managed app development teams, Martin’s articles around software architecture and code quality really resonated with me. 

Just the other day I came across some code that had more comment lines than actual code, and the code that was there wasn’t architecturally sound. It had a somewhat obvious bug due to an oversight as to how a user might interact with the application. This was making remediation of the code difficult and time consuming.

I feel that 4 of the most powerful lessons I’ve learnt in my IT career are:

1. Always understand the root cause of an error. Don’t just “fix” stuff without fully identifying and understanding the root cause.

2. Architect everything modularly. Learning OOP with C++ was probably one of the best things I did very early in my career.

3. Always ask yourself “Will this scale?” or, what will this look like scaled out 10x, 1,000x, 100,000x.

4. Introduce standards fast and early with well documented examples of “why” for others to follow.

I’m going to focus on the “why” in point 4. 

Far too many times I’ve been involved in projects where a rough proof of concept has been developed, the idea catches on and before you know it, badly written developer code is in production.

Martin Fowler correctly points out that the time impact of this becomes realised in weeks not months. More often than not the code won’t scale. More features create more cruft. Finding the root cause of errors becomes more cumbersome and time consuming. Before long, all hands are busy bailing a leaky boat. Rather than finding ways to make the boat sail much faster and leaner.

I feel that point 2 and point 4 go hand in hand. Point 2 is reflected in the 12 Factor app. OOP encourages abstraction, so I’ve always created applications this way. 

The main benefit of standards in my view, is having a whole team code consistently at speed. Everyone can understand everyone else’s code quickly, and there’s a certain amount of quality baked into the code immediately.

It’s likely that some people might cringe at the idea of coding standards, but that might be because they’ve had standards forced upon them with no rhyme or reason.

In my experience, it’s best if the product development team come up with standards together, and agree why a standard is important.

I think another point to emphasise is that this should be a set of guidelines rather than rigid rules that are enforced blindly.

These days many standards exist that you can just pick up and use. PEP8 from Python is a good example. Further to this, most languages now have linters that ensure that developers are adhering to code style recommendations.

Agreeing on things like meaningful names of modules, functions and variables so their purpose is self-evident is a worthwhile investment of time. One example is deciding that all repos for front-end code should have -frontend- in their name, and backend code similar. You won’t need to look in the repo to figure out what part of the application the code deals with. It’s easy to search for packages or modules in the repo, by filtering on these naming conventions. 

I’ve worked with coders that thought the height of genius was writing code nobody else but them could understand. Single letter variable names and aliases. Unnecessary LEFT and RIGHT join statements in SQL. All it does is make the code near impossible to understand, let alone maintain.

Whatever standards you come up with, there should be a sound reason for them. That reason shouldrelate back to quality at scale. Although good standards might mean a 10-15% increase in time to develop initially, when you’re even more time poor later on, that investment will pay huge dividends when it really counts.

Understanding the outcome you’re trying to accomplish with a standard is more important than the means by which you’re trying to accomplish it. I see this a lot in the security, governance and privacy space.

In many large organisations the why, the desired outcome, is completely lost in the complications of the process. The process is so cumbersome, lengthy and unworkable that everyone avoids it whenever they can. This defeats the purpose of it existing in the first place.

When coming up with standards with your team, always frame them with “we want to use this standard so that we accomplish this outcome.” This opens the floor for a better way to accomplish the outcome if the standard is too tight or rigid. 

Ask yourself why the approach might not work rather than validating why it will. What’s the cost and consequences vs the cost and consequence of other options?

I feel it’s just as important to review and revise standards as things change. Are the standards you’ve established still fit for purpose? Are they accomplishing the objectives you intended? Sadly there are far too many times when a development team is stuck on a set way of doing things but have forgotten why they do it that way. There’s a real risk of locking yourself in the dark ages if you’re not reviewing and incrementally improving the effectiveness of your approach.

In summary, establishing some sound standards that encourage common patterns so that new problems can be solved with quality code is a worthwhile investment.

The cost of not doing this is poorly written code that typically doesn’t scale and is difficult and time consuming to maintain. It will almost certainly need to be completely rewritten at some time.

Stop your business going backwards

Posted on by jtconsegna

image1

I just had the pleasure of listening to Kevin Rowland from Ezibuy speak at the Retail NZ Summit in Auckland. My favourite quote from Kevin’s talk was, “Retail is like walking up a down escalator. If you’re standing still, you’re actually going backwards.”

This is true of most business and industry. If you’re not following Ezibuy’s lead and seeing how you can innovate with data and intelligent contact centres like Amazon Connect, you’re likely to be going backwards simply by sticking with the status quo.

It was interesting to see early incarnations of retail, before supermarkets when the owner-operators knew you personally and could make recommendations based on what they knew about you from your regular visits.

With technologies like Amazon Connect, and it’s supporting AWS CX technologies, this level of genuine personalisation is possible in the modern era. One example is checking your order system based on caller id, to ascertain whether the customer is phoning about the status of an order.

The value-add for your call centre staff, is increased call quality by not having to deal with mundane, monotonous calls that a clever Lexbot can deal with.

It’s a win for your business and your team, but most importantly, a win for your customers.

Find out how Consegna can integrate into your existing CRM and support systems with Amazon Connect. connect@consegna.cloud 

 

5 reasons appreciation ensures success

Posted on by jtconsegna

“A person who feels appreciated will always do more than is expected“

This week I put in an unusual sixty hours alongside some of my team members. We all had a number of high pressured, time constrained deliverables: 

A critical workload to migrate during one of our client’s busiest sales periods of the year. An important presentation, to wrap up some world first specialised training the Consegna team have been privileged to receive with AWS. And to top it off, a trip South from Auckland to meet with another client, after  the 2am change the night before – with a “sleep-in” until 5am to catch the flight!

You often hear people on public transport griping about their job and how busy they are. They express how put out they are, how much of a personal burden it is and how much their job really sucks. 

Me? I absolutely loved every minute of it!

How could this be possible you ask? Well here are the five reasons appreciation ensures everyone’s success.

Acknowledgement of effort

Friday afternoon we had to present to the country manager for AWS in NZ, and some of the top ANZ AWS Professional Services team.

Before we got started, the AWS country manager personally thanked us for taking part in the programme we’d been training in, and the massive effort we’d all put in on top of our regular client deliverables. I really appreciate the acknowledgement of effort, it underlined his leadership qualities, and he achieved all that simply with a heart-felt “thanks”.

The internal acknowledgement had well and truly been there, but to get this extra acknowledgement was greatly appreciated.

Having people’s trust

My team and I completed two 2am back-to-back changes after two busy days working well into the evening. We were at pains to make the migration to AWS services as seamless as possible. The pinnacle of the change – nobody even knew the site had switched services. 

Our client was ecstatic, and the careful approach that we’d used paid off.

Changes of this nature in the middle of peak business activity are extremely challenging. It’s only ever possible when you have the absolute trust of your team and your clients. When problems occur, you can’t successfully solve them if people don’t trust in your skills, expertise and ability to solve them. 

We were ultimately successful because even in the face of difficult circumstances, we had our client’s trust and we did everything in our power to validate that trust. Trust is a form of appreciation, and without it, you just can’t be successful.

Making a difference

Earlier this year AWS helped enable their partners and clients with the “Well Architected Review” (WAR) tool. This allows clients to work with AWS partners to review workloads and identify whether or not they are well architected to AWS best practice, and remediate in areas where they’re not.

Among the high pressure deliverables the team had this week, was a WAR with one of our key clients which I lead. The pivotal moment of that exercise arose when, towards the end of it we could all see that there was a lot of work to be done. The client’s team were in a challenging spot, but then this magic moment took place. 

We articulated the following;

“What we have here is a great opportunity to get you to a much better place than you are now. There’s a number of small easy changes we can make, and they’re going to get you a long way towards being well architected. Not only that, operationally your lives are going to be a lot better with these things improved.”

The uplift of demeanour in the room was palpable, and they knew that what was being suggested was achievable. Appreciation doesn’t always come in the form of words. It also comes from the expressions on people’s faces when you are able to deliver workable solutions. It provides a deep sense of satisfaction in what you’re doing, because of the difference it’s making to others. Enabling us to deliver better outcomes for our clients.

Team and Management Support

When you put in big hours and deliver to tight schedules, having the backing of your leadership  and entire team is critical to your success. Knowing that they’re there when you need them is one of the subtler, but more powerful forms of appreciation. It’s also the little things, like your MD buying you a triple shot coffee because he knows you need it!

At Consegna we have a stellar team of people. People who are there even on their day off to support you, just to make sure things go smoothly. That’s true commitment.

It’s a two way street

This week was unusual. We have no interest in our team burning out from long hours, and it was me having to convince my MD and COO that I was OK. If anything I was buzzing and thriving on one of the busiest weeks I’ve had this year. 

Some of the deliverables I’m not sure how I managed. Like putting together a slide deck after a 10 hour day, and still having the energy to present it the next day. Delivery is what we care about at Consegna, and that’s what we’d all been so busy with. Delivering great outcomes for our clients.

Appreciation is quite simple at the end of the day. We get well looked after at Consegna by a committed senior leadership team who have the team and our clients at the forefront of their minds. It’s a necessary two way street. You step up when you need to, and get looked after from end to end.

Personally I don’t see value in time-in-lieu or trying to account for all the time I’ve put in this week. I do it because I care and I love what I do! We get looked after well with team dinners and events, participation and inclusion in specialist AWS training. With fantastic office locations, facilities, and flexible working conditions. We also get all expense paid trips to key events like the AWS Summits and APN Ambassador events. These allow us to expand our knowledge and further hone our skills for the business.

When appreciation flows both ways success is inevitable. With delivery a focal point at Consegna, appreciation and trust in our team is what makes us a success.  

 

What does the CD in CICD actually mean?

Posted on by jtconsegna

It’s occurred to me fairly recently that there’s sufficient confusion about what the CD in CICD stands for, to warrant some simple explanation. I’m not even certain that people generally understand the CI part either. I’ve noticed on a few occasions developers tend to say, “A CICD pipeline is an automated way of delivering code into production.” I feel this is often interpreted as, “you commit code over here in your repository, and it automagically pops up in production over there.”

“What on earth could possibly go wrong with that?” the system operations team might ask sarcastically, turning distinctly green then pale at the thought of developers having ultimate control over production releases. I’ve also noticed non-developers ask, “Is it Continuous Delivery, or Continuous Deployment?” Is there even a difference? It seems a number of people interchange Delivery and Deployment without really understanding what each of them actually is. Isn’t this just typical developer double-speak for exactly the same thing?

To provide some historical context to this explanation, it’s useful to understand software development life cycles before Virtualisation and Cloud. Right up until the mid-2000s, software feature releases were typically very slow. Products might have gone four years before they got an update, and the savvy never installed a “dot-one” (.1) release, let alone a dot zero (.0). Frequently they were buggy and unreliable. It often wasn’t until a “one- dot-two” (1.2) release that people started getting any confidence. Even then, that only ensured catastrophic bugs were eliminated. Other glitchy behaviours often still existed but didn’t contribute to a total loss of work.
“You do back up your work every half hour right?” was the catch cry long before Cloud, autosave and versioning were as widespread as it is today.

A significant change that virtualisation helped bring about, was the ability to more cheaply run a non-production staging environment. A place to test out new changes before releasing them into production. Cloud via infrastructure as code makes non-production environments even faster, easier and cheaper to provision for testing purposes. The key to an effective staging environment is that it’s as Production-like as possible. This helps avoid embarrassing and costly “roll-backs” when code changes don’t behave in production as expected because there was too much variation between prod and non-prod.

Running in parallel to these infrastructure changes was the development and rapid adoption of software version control systems. In the bad old days, files were versioned by either commenting out old lines of code and introducing new lines. Alternatively, old files on production servers were renamed, and new files introduced in their place. It was less than ideal and alarmingly widespread. “When was the last backup done?” wasn’t something you wanted to hear in a development team. It often meant somebody had overwritten something they shouldn’t have.

Version control in the form of SVN, then later Git and other alternatives allowed a new copy of a code file to be added to a repository, and the old version kept completely intact. What’s more, the developer could comment during the commit, what had been changed.
This lead to the practice of Continuous Integration (CI), where developers could collaborate together more rapidly by sharing small code changes via the version control repository, and by doing so, minimise the impact each code change had on others. Everyone was effectively working on the same code base, rather than having separate copies that diverged more and more widely, the longer each developer worked on their private copy of the code.

This brings us then to Continuous Delivery which is the automatic build and test of committed code changes with the aim of having production ready features available for release. Getting to Continuous Delivery after the successful implementation of Continuous Integration is relatively straight forward using AWS Services. By using Code Pipeline to automate the test and build of code commits, most of the tooling required is readily available.
AWS services like Elastic Beanstalk make it incredibly simple to replicate production application stacks into non-production environments for testing. AWS OpsWorks and CloudFormation can greatly simplify the reproduction of more complex application stacks for production-like staging.

Many organisations get to Continuous Delivery and don’t adopt Continuous Deployment. They either use a manual authorisation step to deploy changes into production or a semi-automated delivery approach of code into production. Continuous Deployment then is the automatic deployment of production-ready code into production with no manual interventions. If changes fail the build and test processes, they are rejected and sent back to the development team for revision. If however, all changes pass the test, they are automatically deployed into production, and this is continuous deployment.

The fundamental key to all this working well is small frequent changes. The historic issue with large complex changes over an extended period of time was that the root cause of any particular issue was extremely difficult to pin down. This made people reluctant to release changes unless it was absolutely necessary. With the collaboration made possible by Continuous Integration, it ensures everyone is working on a single code base. This prevents accumulative errors common when everyone is working in isolation on big changes.

So there is an important distinction between Continuous Delivery and Continuous Deployment. The latter can be arrived at in an incremental manner after successfully adopting CI, then getting continuous delivery and testing to a robust enough point that well vetted, small feature changes can be continuously deployed into production.

Consegna have significant experience in helping organisations adopt CICD successfully. If you’d like to find out more information, email hello@consegna.cloud.

NZTA All-Access Hackathon

Posted on by jtconsegna

Consegna and AWS are proud to be sponsoring the NZTA Hackathon again this year. The event will be held the weekend of 21 – 23 September.

Last year’s event, Save One More Life, was a huge success and the winner’s concept has been used to help shape legislation in order to support its adoption nationally.
The information session held in the Auckland NZTA Innovation space last night, provided great insight into this years event which focuses on accessible transport options, in other words making transport more accessible to everyone, especially those without access to their own car, the disabled, and others in the community who are isolated due to limited transportation options.

The importance of diversity among the teams was a strong theme during the evening. For this event in particular, diverse teams are going to have an edge, as Luke Krieg, the Senior Manager of Innovation NZTA, pointed out, “Data can only tell you so much about a situation. It’s not until you talk to people, that the real insights appear – and what the data alone doesn’t reveal also becomes evident.”

Jane Strange, CX Improvement Lead NZTA, illustrated this point nicely with a bell curve that shows the relationship between users at each extreme of the transport accessibility graph.

Those on the right with high income, urban location, proximity to and choice of transport options invariably define transport policy for those to the left of the curve who are those with low income, located in suburban or rural areas, who are typically more isolated and have fewer transport options.

Luke also stressed how much more successful diverse teams participating in Hackathons usually are. As these are time-boxed events that require a broad spectrum of skills, technology in and of itself often doesn’t win out. Diverse skills are essential to a winning team.

For more information and registration to the event, please visit https://nzta.govt.nz/all-access

 

Why Cloud is Relevant to Your Business Today

Posted on by jtconsegna

As the newly appointed ICT Manager for a large government agency, Jeff was keen to make his mark quickly and decisively in his new role. Looking at the IT spend over the last three years, he could see that in spite of the market shifting considerably, the agency had been paying exorbitant amounts for application hosting. The market had trended downwards with pressure from large Cloud providers like AWS. Looking at their hosting arrangements more closely, Jeff could not only see their costs remained largely unchanged but also, service reliability had been steadily declining. This project looked like an ideal candidate to reduce cost, increase service levels, and make the mark he wanted.

After looking at the current environment carefully, a current rebuild of the primary public website for the agency appeared to be a good choice. The site was currently in development using AWS services. The development team had chosen AWS for development due to its low cost, well within their budget. Far more compelling to them was the speed with which the developers could provision and utilise the necessary resources. What would typically take internal IT weeks to provide for the developers could be accomplished inside a day using AWS management tools and company best practice.
Using managed services such as AWS Elastic Beanstalk, not only did the development team have ready access to a low-cost development environment they could provision on demand. They could also run parallel application stacks for testing. That just wasn’t possible using their existing infrastructure that was difficult to access and manage. As such, the AWS services allowed new configurations to be tested quickly at a fraction of the cost of traditional infrastructure. Cents per hour, versus a few hundred dollars a month.

With the application completed, launch day and migration commenced. Fortunately, Jeff had identified that the team needed an AWS partner to assist with the migration. This lead to the realisation that a scalable architecture was required to support the fluctuating demand on the website. With the right design, the right AWS partner, the site was migrated and delivered a 75% saving on the former hosting costs. With the automated scaling and monitoring, AWS services provided as part of the production environment, site outages dropped to less than 1% over first few months of operation, improving even more over time. The site had gone from 2 – 3 outages per month on the old hosting, due to network and other issues, to no unscheduled outages from one month to the next.

At this point, one would think this would be the end of the story. The primary production site was on AWS at a fraction of the former cost. Service levels were higher than they ever had been. The new problem that was beginning to emerge was cost control and environmental regulation.

With the success of this project, Jeff’s teams started moving more and more projects to AWS. As more teams in the organisation also adopted this approach, keeping an eye on resource usage started becoming more challenging. Managing what teams and individuals had access to resources was also emerging as a challenge. The situation Jeff was finding himself in after an initial easy win is quite common. Many companies who discovered server virtualisation during the mid-2000’s also learned technology on its own can create all new challenges nobody had previously anticipated.

The simple answer to why Cloud is relevant to your business today is the agility it provides and the transfer of CapEx to OpEx. Not to mention the tangible cost savings you can make. What’s important for ICT managers to understand, however, is the importance of a structured approach to Cloud Adoption. Not every workload is going to be a suitable candidate for migration. Ongoing success requires the implementation of a Cloud Adoption Framework (CAF) and the establishment of a Cloud Centre of Excellence (CCoE). Neither of which need to be as daunting as they sound. The CAF examines your current environment and assesses what workloads would work in the Cloud. It highlights six perspectives around Business, People, Governance, Platform, Security, and Operations. In so doing, it ensures thought is given to each of these within the context of Cloud. What training do your people need for example, when a particular application gets migrated to the Cloud? How would their roles change? What operational support would they need?

A CCoE should be seen as the thought leadership and delivery enablement team that will help plan and execute on the CAF. It usually consists of SMEs from each principal area the CAF examines. By choosing an AWS Consulting Partner like Consegna, who understand this pragmatic, structured approach to cloud adoption and digital transformation, ongoing long-term success starts from a solid foundation.

The discoveries Jeff made during his journey to Cloud are being made by ICT managers on a near-daily basis. An increasing number of Jeff’s peers understand that Cloud is a timely and necessary step to reduce cost and increase agile productivity. Those with that extra slice of understanding and knowledge are working with partners like Consegna to do Digital Transformation the smart way. Putting CAF and CCoE at the forefront of their journey, and seeing great successes in doing so.

Why is CAF Critical to Cloud Adoption?

Posted on by jtconsegna

An all too familiar scenario playing out in numerous organisations today is a rapid push onto the Cloud.  Typically this entails a technical division getting approval to migrate a workload onto to the Cloud, or establish a new project on AWS EC2 instances.

Fast forward a few months and the organisation’s cloud adoption seems to be progressing fairly well.  More and more teams and applications are running on AWS, but it’s around this time that cost and management have started spiralling out of control.  A quick survey of the organisation’s AWS account reveals there are users, instances and various other resources running out of control “on the cloud”.  The typical issues many organisations have wrestled with in their traditional infrastructure space has been directly translated onto the Cloud.  Now the financial controller and other executives are starting to question the whole Cloud strategy.  What exactly has gone wrong here?

Whether you’re prototyping a small proof of concept (POC) or looking to migrate your entire organisation into the Cloud, if you fail to adhere to a Cloud Adoption Framework (CAF) and form a Cloud Centre of Excellence (CCoE), it won’t be a case of if the wheels fall off the wagon, but when.

Think of the CAF as a structured roadmap that outlines how and when you’re going to migrate onto the Cloud, and the CCoE as the project leadership team who will be able to execute the CAF in a manner that will guarantee results.

The CAF looks at Cloud Adoption from six different perspectives. Business, People, Governance, Platform, Security and Operations.

 

It ensures that no matter what project you have in mind, the broader implications of Cloud adoption are highlighted and worked through.  If you’ve ever been privy to the disaster an ad-hoc technology lead adoption results in, you’ll truly appreciate how critical CAF is to successful Cloud transformation.

Consegna specialise in running CAF workshops for organisations to ensure success with end to end Cloud transformation, both from a Business and Technical perspective, for complete Cloud adoption.  For a coffee and chat about CAF and how it can ensure the success of your Cloud migration and digital transformation, contact sales@consegna.cloud for a catch up.

How Do You Assess A Trusted Cloud Partner?

Posted on by jtconsegna

When it comes to digital transformation and cloud adoption, a trusted advisor with the right experience is a crucial component to your success.  How do you evaluate your options?

Case studies such as the one recently published by Consegna.Cloud, highlight the challenges and solutions provided, giving key decision makers essential insights into the scope and scale of other projects in relation to their own.

 

Case Study

 

Key points of interest in the case study are identifying the complexity of the project.  For example, in the QV case study Consegna recently published, the existing systems were almost twenty years old, so a mature system with a lot of legacy components.  Thus, a high level of complexity.

Case studies also highlight the key benefits the project delivered.  In the case of QV, over 50% savings on Infrastructure costs alone.  Please look for these key metrics as you read through the case study.

Such artefacts are useful in establishing the evidence based capabilities that Consegna, a trusted Cloud advisor, possess.  Feel free to contact the Consegna team to ascertain how your project compares to the QV project.  Simply email sales@consegna.cloud  to start the conversation.