Sunday, December 29, 2013

Software low barrier to entry not necessarily good

Generally, in the technology industry, the mantra is that barrier to entry for software is low. There are multiple reasons for this, but the primary reason is that software requires very little physical pieces to get started with and there is a lot of documentation out there. This is unlike other industries such as :

Hardware - which requires hardware components, physical goods, durable materials. Examples: Computers, phones, appliances

Retail - which requires having expensive physical stores built-out to attract customers

Hospitality - which requires having attractive, physical spaces to allow individuals to be entertained/housed at, such as hotels, resorts, and/or cruises.

Because of this belief, generally, it is believed software is a great industry to get into. However, after being in industry for close to three decades (I started when I was 10), I argue that having a low barrier-to-entry is more of a hindrance than advantageous for the software industry. 

In the early days of software, before distribution was easy to do over the internet, there was a premium to buying a physical good, i.e., a software package, for hundreds, sometimes, thousands of dollars, to build out applications on desktop computers. Alongside knowledge and documentation was sparse and hard to find except only in the hands of industry professionals through bookstores and the companies that built the packages. Examples of this include Borland's development tools, Microsoft development tools, middle-wares such as CORBA or EBS, or PowerBuilder. There was no such thing as try before you buy in those days. 

These days, software packages and documentation are easier to acquire across the spectrum, from low quality to higher quality, for free to mere hundreds of dollars to get started. If there's enough interest, intellect, and momentum, almost anyone can pick up a software package and develop software for desktop, web, mobile, or embedded systems.

However, due to the high investment of higher barrier-to-entry industries, there is an incentive to create something that is different, competitive, appealing, and interesting for the consumer.

With lower-barrier-to-entry, as we are now seeing, the level of quality of resources and deliverables in the industry have gotten lower and lower over time. An example is software development tools are not as good as they used to be and, as a result, the software itself has suffered. Games industry is another industry that have become highly fragmented. Very few companies have done a good job in keeping up with the concept of premium and quality, which are those that have a high investment. The companies that do not are the ones that anyone is picking up and using pure short-cuts and non-thoroughness to build what I call crudware. From what I've experienced and seen in the past and today, there is a lot of crudware out there today.

One may argue that low-barrier is better because this empowers those who may not have been able to participate if it was high-barrier. I would say these individuals also do not think through as clearly what they are building which results in lower quality products that beg the question why it was even built in the first place. A lot has to go into quality software, such as UI experience, requirements, understanding what the customer wants, graphical and font elements, and finally consideration of multiple screens (web/mobile,etc).

Finally, we have gotten into a position of "ready, fire, aim", which costs a lot more in terms of time and people resources to get a quality piece of software out that is usable and makes sense on why one would use it in the long term. Most companies get to "Ready, fire" (which are seed/a-round investments", but aim fizzles way. Which in turn, results in consistent low quality and, frankly, as we are seeing, low ROI and waste for 99% of the software technology companies out there. This in turn does not help the investors.

A good metric for that is to look at companies that were mentioned in publications such as TechCrunch, Business Insider, or Gizmodo a year ago, and look now. You will notice most of these companies are not in existence anymore. Lower barrier entry results in lower quality industry.

My suggestion is if you were going to go into software development, instead of seeing what is the minimal you would need for seed, first start with what you would do if you had $2 million investment. And then break it down into iterations of the company. This will put more thought into how you would recoup the $2 million investment over a 3-5 year timeframe. And as VCs, this is what I would recommend looking at. This is what has to be done in high barrier-to-entry industries. If we treat software as a high barrier-to-entry industry, we will get high barrier-to-entry industry quality.

You can not do it all in one iteration, plan what you release and when you release.

Wednesday, December 4, 2013

7 layer burrito architectures and it's drawbacks

As I talk to different companies, there are places that exhibit what I have dubbed the "7-layer burrito" architecture. Of course, this name comes from the 7-layer burrito that Taco Bell sells.

As a food item, it's delicious. As an infrastructure or software architecture, it's not advantageous for an organization.

A 7-layer burrito architecture is an infrastructure architecture that has added layer upon layer of systems because:

1) There was not time to refactor or refactoring was not done completely.
2) There's a new technology that is "cool", so they must have it.
3) A belief that more layers are better - "bigger is better".

7-layer burrito architectures, of course, does not mean exactly 7-layers. But, if any organization goes to 7-layers, it should rethink what they're doing and focus on minimizing.

Personally, I like simple. The lesser the number of layers:

1) The less time spent maintaining and up keeping of each layer as new versions come out. Including testing, debugging, and fixing integrations.
2) More time is available from the team to work on value-added items.
3) The speed to debug and fix production issues is faster because there are less layers to roll through to find the root cause.
4) The speed to process and deliver information is faster.

If any organization does have a 7-layer burrito architecture, they do need to rethink why it is there and find ways to minimize it. Else, the organization can become bloated and slow down throughput tremendously.

At AcceleWeb, our architectures are simple. We have no more then 3 layers of infrastructure to support our sites, and believe that these days, very few organizations need more then 5. As the number of layers increase beyond 5, the architecture gets derailed by complexities in handling each addiitonal layer.

I would love to hear from others their thoughts.




Thursday, November 21, 2013

Technology teams are stakeholders, not cost centers


The definition of a stakeholder is: a person with an interest or concern in something, esp. a business.

Currently, technology teams are looked at as cost centers. With the definition above, I argue that technology teams are stakeholders, not cost centers, and should be viewed that way by the business and the technology leadership.

The reason I say this is because there is a symbiotic relationship. Given the scenario a business is dependent on a technology team, technology teams cannot be present without support of the business.

As a result, technology teams should view themselves as stakeholders, in which they are providing value back to the business, which would hopefully grow through technology product and operational efforts ( see http://acceleweb.blogspot.com/2013/09/product-oriented-technologists-vs.html). From there, investments occur back into the technology team in terms of employment, growth, higher budgets, increased compensation/incentives, and business knowledge/understanding. This allows for an increased demand for technologists at the organization level, and in turn, at the industry level, which raises the value of technologists as a whole.

As a result, I view technology teams as stakeholders, not a cost center. With this lens, the way a technology team member views themselves individually changes dramatically, which I would hope increases productivity and ROI from the technology teams out there. If the teams understand that they are providing value back to the business, instead of just a cost center that bleeds dollars, I think there would be higher motivation from the team itself to do better.

Tuesday, November 5, 2013

People scaling in technology teams

In technology, we discuss scaling up technology to support traffic and growth. What is not mentioned, however, is a concept called people scaling.

People are the most expensive part of any tech organization. They are compensated for their thoughts and ideas to build and maintain systems and software for the business. So, when it comes to technology scaling, there is an upward dependency on people scaling.

What exactly is people scaling?

People scaling is :

1) Freeing up time from your most valuable people to open up capabilities from them to increase innovation and operational efficiencies.

2) Removing dependency on one core individual to be the brain of the whole team and dissipating that responsibility through the tech organization. Not only will this allow the team to grow, but it will also allow more thought-leadership to come from the core individual and provide mentorship/growth to the rest of the team.

3) Opening up time for the team to solidify existing systems so that there's no angst or lack of sleep in the organization from downtimes or slowdowns.

4) Increasing time for technologists to think through new and innovative ideas, do proof of concepts, and present these ideas to business. I believe for organizations that have a strong technology presence to succeed, it's important to have new ideas to not only come from product or business teams, but also from technology. For this to happen, the technology team needs to have time to work on these ideas to determine if they are feasible. This work should not be done outside of the work hours in their personal time, but during work hours, where they can collaborate with other technologists and not take their own personal time to do company work.

5) Keeping the team consistent. For an organization to stay competitive, the team must be as stable and consistent as possible. A team that has been there a long time understands the business, the technology, has history, and formed relationships with key business partners and with their own team members. Any change in the team has an exponential ripple effect the takes time away for training, expectations management, and ramp-up.

Instead of organizations properly people scaling technology teams, usually it's just hire more contractors or consultants.  Contractors and consultants are good to add to the team for support, but they should not be added until the organization has properly scaled up its own people to be able to provide more time back to the organization without asking the team to work unreasonable hours.

At AcceleWeb, Inc , we understand this and maximize our people effectively to be able to do more with less.


Friday, September 13, 2013

Product-oriented technologists vs operations-oriented technologists

In the tech world, there are two types of technologists: Product-oriented and Operations-oriented. In this case, when I mean operations-oriented, I do not mean sysops or devops, but as a higher-level categorization.

Product-oriented technologists work closer on revenue generating and efficiency-improvement initiatives, such as media-based  systems with CMS, learning systems, ecommerce, cloud computing, big data and/or mobile. They generally have a better understanding of the business, know how to narrow the gap between business and tech, participate in roadmaps, and can provide product-level value add to the business to help support and grow with the application and back-end systems. They also work on making sure the servers are set up correctly and configured to support the product with speed, functionality, and performance.

Operations-oriented technologists work closer on keeping the lights on, making sure patches are up-to-date, bugs are fixed, and minor enhancements and features are completed. They generally need direction on initiatives from product-oriented technologists to help keep things moving forward at an accelerated pace so that the gap between business and tech can be as narrow as possible.

In the tech world, both types of roles are needed. Organizations in growth mode tend to lean towards product-oriented technologists while organizations in sustainability mode tend to lean towards operations-oriented technologists.

Product oriented technologists generally can veer towards play the role of an operations-oriented technologists. However, product-oriented technologists are not as interested in being operations-oriented for a long term. As a result, many end up leaving once a company goes from growth to sustainability mode.

On the other hand, operations-oriented technologists tend to stay at organizations for much longer, as their value is to sustain the business and are not as interested in product level initiatives.

Finally, industry-wide, there is more of a demand for operations-oriented technologists due to many organizations tending to move to sustainability mode and in need of a larger pool of technologists as the organization grows the business on the backs of the products that have been built.

At AcceleWeb, we are proud to be a product-oriented organization with product-oriented technologists. We are consistently creating and improving our applications and systems to be able to provide the best-in-class services to our customers.


Wednesday, August 14, 2013

Don't hire a "technical architect" without understanding what you want.

In my opinion, positions that need to be hired, with folks you have not worked with, into an "architect" title that has no clear roles/responsibilities is asinine. Ask 100 different people what an architect's roles/responsibilities are, you will get a 100 different answers.

I continuously get requests for a company looking for an architect. When asked what are the roles/responsibilities, some say "it's a management role", others say "heres a list of technical items you should know" with no clear understanding of the position itself. My favorite is "you do everything technical" <== I don't understand this. Does that mean product development? Managing tech projects/people? Development? Infrastructure? Building out systems? Doing drawings all day?

If the roles/responsibilities are unknown, then it's a failure on management to understand what the need is and what the expectations of commitment is from the individual.

Finally, hiring an architect that is an unknown without clear expectations puts the individual in a detrimental position, because they do not know the systems, the apps, or the business well enough to effectively do their job.

So, the organization is better off doing one of the following :

1) Hiring a senior developer that has the potential of being promoted over time to architect.

2) Make it a tech manager position, if that is the intention, and allow them to effectively manage.

3) If the hiring manager and the architect candidate that needs to be hired in have worked together before (either in a full time or a consultancy capacity), then it's an option to bring that individual in, as there are clear expectations from both sides on the role and, more then likely, the manager is in a similar industry/work environment as before to allow the architect to do his job effectively.

4) Hire an "architect" that is proven in industry through blogs, books, or speeches so that the manager understands their capabilities/expectations.

5) Be very clear on the roles/responsibilities of the individual coming in and stick to them, do not continuously re-prioritize.

However, don't ever make an "architect" role and hire someone in that's unknown without clear expectations. It will not work or will be excruciatingly difficult.


Friday, August 9, 2013

CTO/VP at small companies/startups… really?!


I’ve been getting a lot of calls for “CTO”  or “VP” technology positions for start-ups.

Come on guys, a 2-5 person company where one person is the CEO does not make the tech partner a CTO >OR< VP. Put it as how it really is, they’re a senior engineer. Especially, since the senior engineer will be busy coding up your little website or mobile app, setting up servers, figuring out hosting providers, collecting requirements, working on designs, and trying to appease the CEO.

Trying to market a senior engineering role as a CTO or VP is detrimental to the employee and the company. What happens is in 2 years, >if< the company does gain any momentum, that individual who is a CTO or VP will be replaced by another more senior CTO or VP. Suddenly, the senior engineer exits the company out of the weirdocity of it all and the company loses someone that has knowledge and experience.

Giving equity and a piddly salary does not help the morale of the employee or the sustainability of the organization.

Why not instead just give that person a senior engineer title and let nature takes it course? It will make it less comfortable for both parties and, honestly, at the end, probably put the company in a better position.

The problem Google Goggles is trying to solve


A lot of people I talk to in industry and articles talk about the problems with Google Googles and associated issues. Also, many mention why anyone would use it?

Well, it’s actually trying to solve a problem. When I was out yesterday walking the streets of Manhattan, I saw a lot of people head down looking at maps/head up looking to see where they’re going, rinse, repeat to get to their location.

So how can you view maps and see where you’re going at the same time? That’s the problem Goggles’ is trying to solve.

I don’t have an opinion until all the kinks and legalities are worked out, and I have had a chance to try it
– but at least Google’s trying to solve the problem of the kinked neck.

The other solution is to set up GPS voice navigation to an earbud, but my experience with voice navigation is it’s flaky, so there is an element of distrust in it, imo.

Separation of functionality and data


Today’s structures for software development is basically two distinct separate pieces. This is true for any software that is developed:

1) Features/functionality/framework to let users munge, CRUD, maintain data.

2) Data storage and retrieval systems.

It got me thinking this approach has not changed in over 30 years in software development. That said, this is the same approach that has been used even before software development became an industry.

Examples: Televisions are features/functionality/framework, television shows are the data that is exposed. Movies are same with movie theaters and movies. Even you can, with a small leap of faith, claim that real estate has apartments, office buildings, etc as features/functionality/frameworks and the “data” are the tenants using it.

As humans, we’ve evolved into two piaces of products we make in general –
Features/functionality/frame work and data to utilize it.

It makes me wonder if this is how we’ll continue, or if we need to restructure to come to a different type structure for us to move to a new level of optimization. I am not sure what this would be, but it is an interesting paradigm we’re in.

Mobile vs Web usabilities


I have a laptop and a mobile phone. Why is it that some features are better on mobile and are not easily replicable on the desktop versions? It seems like things that should be simple to do on a desktop is just not there, but it’s simpler on mobile, that I have to go between the two.

A few examples are:

- Google Places – GREAT feature on Google Maps to find contextual places near an address. However, to do a similar feature on desktop, there’s no Google places button. You actually have to search and find near by.

- Newsreaders on desktops are a pain. On mobile, it’s easier to digest and view news. I use Pulse, and Pulse on the desktop is just awful. It’s slow, harder to navigate, and painful to use.

- Linkedin on mobile’s great, especially these days. The desktop version is a plethora of items that’s difficult to navigate and focus on what you want. The mobile version, on the other hand, is elegant, and easy to navigate to information that you want.

- Most of the major email clients on mobile are great. The desktop versions also have the same issue of navigation.

Now, I get this push for mobile, but sacrificing the desktop version for mobile is a bad idea. After all, more people still use desktop versions of these web applications then on mobile.