Entrepreneurs

The vast and free source of power that we often overlook

/ timmeeuwissen / Leave a comment

I am convinced that a compliment that I have for someone else, isn’t mine to keep.

We often keep our praises and compliments for someone else for ourselves. Sometimes they are shallow, like seeing that a female co-worker has made an extra effort on her hair today or someone bought new shoes. But sometimes they run deeper, like appreciating the time someone has taken to educate you on something or be thoughtful of your private situation.

It is key to express yourself. Speak up! Inner whispers cannot be heard.

Fear

We often fear that we miscommunicate, so we refrain from communicating at all. Thoughts like:

  • Does he think I try to curry favors
  • I’m afraid that she thinks I try to hit on her
  • This person always works this good, giving a compliment now is silly
  • I think it’s inappropriate for me to say this since he or she is so much higher in the chain

are quickly in mind. There’s thousands of reasons to not do it, and it takes courage to do it.

Why should you do it anyhow?

Even though it’s hard, there are some good reasons to do it anyhow. You will see that when you practice this more often, the process will become much easier after a while.

  • Positivity is infectious. A single positive word from a person you respect dearly can make you go home and tell your friends and family about it. You did well, made effort and somebody saw and valued it. Your day can be filled with an empowering feeling that makes you perform better than ever.
  • Positive reinforcement steers better than punishment. Instead of telling what shouldn’t be done, appraise what should be done and people will follow that route.
  • It’s okay to give people compliments when you feel insecure if they are appropriate, just make sure you also tell them your doubts (in not too much detail) about giving them.
  • Telling that things are bad, will make people lose their faith and lust to work. The inverse of that is also true. Telling people they are doing good will make them feel reinforced and want to become better.
  • Threat others the way you want to be treated yourself.
  • By being thoughtful, you can create a bond of trust. This bond (especially for leaders) is necessary when times are more rough and you need your influencing skills to steer the ship with the nose in to the waves.

For leaders

To put some more emphasis on the last point, remember that trust is:

Of the three factors you can influence as a leader, at least one third is controlled by intimacy which is built by honesty, respect and a watchful eye to the person and their situation and needs. A kind sincere recognition can go a long way!

Conclusion

Take the feeling that you have when you feel recognized and verbally rewarded. That power is also within you to give to someone else. Be carefull when to apply it, and don’t overdo it. But be confident that when you think it’s time to do it, it should be done without reconsidering. Bite your tongue and wait for the response. Observe and learn from what you’ve just done.

Be conscious of the power you have unleashed to shape the day of someone else

 

 

Why and When to do Behavioral or Test Driven Development (B/T)DD

/ timmeeuwissen / Leave a comment

For: Teamleads, Architects, Entrepreneurs and QA members that are searching for a path to higher quality.

Generally, testing is perceived as boring, time consuming and ‘expensive’. This is also the first question business people will ask when you propose it. ‘Fine, but how much does it cost?’. This article should give you some sort of a hand-hold to determine what it might bring you and if the time is right.

How to test your stuff, isn’t as valuable if you don’t have a solid understanding of the Why and When. I have written a post on how to implement TDD in a TypeScript build-process, about the how. Now it’s time for the reasons behind it.

When to start with automated testing

It’s in my opinion foolish to immediately start with writing tests when you start with creating a new product. Often you really don’t know what the product will become (you might think you do, but really, usually you don’t, read about this in The Lean Startup from Eric Ries). There will be many iterations of pivoting that will cause your application to go a completely different way when you build an MVP (Minimally Viable Product).

But once the product found it’s way in to the market, and the goals become more and more long-term, your focus will start to shift from creating new stuff, to make sure we create the good stuff. Code gets refactored all the time to be more performant and better readable. But stuff will break all the time.

At this moment your code will – and should – be tested to maintain a certain level of quality. This is the moment Automated Testing steps in.

Why would I do automated testing

I mean, developers know what they’ve done right? They can check what they’ve created?

That’s the general over-simplification we hear. It’s true in some sense, and happens always to reach your Acceptance Criteria, but it won’t suffice. With automated tests you can:

  • Run automated tests before merging to stable to know you are safe and automated rollout to staging or even production (Continuous Integration / Deployment)
  • Test against hundreds of browsers and their versions, on different devices and operating systems
  • Prevent regression
  • The tests define functionality. They are the place you can go to to find an example of integration
  • Do code coverage checks that give you information on how much of your code is covered by tests.
  • They cut time and reduce the risks that you have when going to production. It builds in a certain amount of certainty. Whenever a bug does slip in, you can write new tests to check for that issue. This makes sure that the exact bug doesn’t re-occur (hence regression tests)

What does the T/B DD stand for?

TDD means Test Driven Development

When you read it carefully, you see “Driven Development” trailing the first word “Test”.  This basically means: write your tests before you start writing any code at all. So, what are the benefits of doing this?

  • By writing your test first, you’ll have to think about the thing you are creating. Think about the outlines, the how and what. Since you are still not really hands-on, you also don’t have to improvise and be burdened by hacking stuff in to make it work. You just think about the feature or the unit that you want to add to the system. This makes your code mode atomically correct once you start writing and you’ll spot issues before they arise.
  • Now we know wat we can expect from the thing we want to create, we start running the test. The test will fail since the code for your new test isn’t there yet.
  • You iterate over your code to make your tests green, and if needed add other tests if the functionality isn’t sufficient yet, and start this process all over again.
  • You’ll deliver code that is restricted to what’s asked from it, not what future questions might be. You’ll deliver code that works, and what others can rely on.  All features are documented.

TDD is often synonym for Unit Testing. Unit testing means, each unit of your code should be testable as a separate black-box apart from the complete system. You’ll see that you’ll be mimicking the file structure of the original project. Don’t merge the two together although this might be tempting! Tests should run separate from your production code. Your code should never rely on your tests. Your tests should only rely on units of your code.

BDD stands for Behavioral Driven Development

So the ‘Driven Development’ is exactly the same as for TDD, but in this case we don’t test units, but the sum of their outcome. These units combined create an experience for the user, and your scrum stories rarely contain AC’s with the granularity of a Unit. To properly test the code, we’ll have to do integral tests that measure if all criteria for AC’s are met.

With BDD we:

  • click through the website
  • expect functionality to be there
  • finish operations, like creating a basket and ordering
  • test if the outcome is as desired.
  • If not correct, take screenshot, log errors and alarm.

This means:

  • have all AC written in a structural way
  • test AC in human readable text against our production and test environment
  • develop a feature base (since we already keep track of AC) that informs the next person about the what, why and how of all features in our application.

I can advise ChimpJS to do this for you, while writing your tests in Cucumber syntax. This is friendly for as well as Business as Tech. Here’s a great example of how that would look like!

 

What does testing cost?

So to finish with the first thing that will be asked. Investing in automated testing does cost money, but a lot less than humans doing the same thing.

The question really is, how much can you afford to screw up?

If the answer to that is: I don’t mind, then don’t do it. Because you wouldn’t hire a human to test either.

If the answer is: I do mind a bit but I don’t want to invest too much, then make sure that all software that is tightly related to KPIs is automatically tested. You will see that over time it will give you more than it costs you.

If testing is already an integral respected part of your deployment routine but not digitized yet, I would say: read this article again and draw your own conclusions.

 

Testing isn’t giving you 100% assurance. Nothing does. But you can always try to become better at what you do, and with that idea in mind be sure that you structurally test whenever changes are being made. I once spoke with a CTO that had a complete division of testers, that wrote tests apart from the development teams. To my recollection both teams where about equal in size. What we should learn from this is: when there is much at stake, you must do more to make sure things go right.

How much is for you at stake?

Let me know what you think in the comments! Want more of this? Use the Poll on the right of the screen, comment or contact me!

Why use Story points or Time for resource tracking

/ timmeeuwissen / Leave a comment

For: team leads and Entrepreneurs

Running a service oriented business isn’t the same as running a product oriented business.  There’s a major difference and over the course of time I’ve learnt where the differences are when it comes to resource tracking, and how that may or may not affect your business.

Resource Tracking based on Time (more service oriented)

Pros:

  • enables to have specific billing, which feature costs how much money exactly
  • prospects and invoices can be compared to see how budgets are met
  • you can track individual progress and troubleshoot on real fine level when things aren’t going well
  • works exceptionally well for time-to-time small ad-hoc services

But the cons weigh more heavy:

  • time tracking is a pitfall for managers to start micro-managing
  • it kills creativity
  • it drives quality down (you assess on time, not on result)
  • there’s large amounts of overhead and overthinking for the developer
    was I effective this 15 minutes? And, I had to google a lot for this feature, should the customer pay for this?
  • employee satisfaction but also effectivity is strengthened when the employee feels at comfort. The best idea’s come to you when you’re not actively trying to solve something. Opportunity for relaxing is in that sense just as important for the employer than the employee (mind you, there should be a good balance here. Of which part of can be obtained by having a good thorough intake). When the employee has to meet up to the set 8 hours of his job he’ll feel at discomfort when he sat down and stared out of the window for half an hour, even though this time might have solved lots of other stuff. At the end of the day he or she will start with creative bookkeeping which will result in lots of negative energy that could have been used for positivity.

Resource tracking with story points (more product oriented)

When you start resource tracking with story points:

  • all points will be relative to one another.
  • developer doesn’t have to think about the client. They just have to think about what it’s relatively costing to another task
  • tasks get easier separable, since they can now be defined without having to speak in understandable business terms.
  • story points have relative value. This eliminates that the speed of the individual developer is weighed in the estimation
  • more focus towards quality

But how do you sell this:

  • Measure in Complexity and Uncertainty, not Effort
    • Complexity consists of how hard it is to clear the job. E.g. it touches lots of repositories, we have to align with lots of people and the subject is very delicate. This would be a high complexity.
    • Uncertainty gets weighed in, because it is key that during grooming sessions this factor gets reduced to a minimum. The more certain something is, the smaller the task can be, the better it is estimable but also deliverable for the allocated number of story points. So if either your PO or yourself don’t have high confidence and feel uncertain how to solve the task, you should start splitting what is clear and what isn’t, to maintain deliverable stories. External dependencies are uncertainties as well.
    • Effort gets pulled out. It’s silly to do simple stuff for lots of times and your customer shouldn’t have to pay for silliness. This is where you have to play smart, and say: changing all files by hand would take me 10 hours, so I will have to write a converter that does exactly this, this and that, which will only drive up the complexity, and thus the investment in to getting this topic solved.
      By doing this, you get rid of your legacy topics. Programmers should be lazy and automate everything they can. This should be part of the routine, because your PO ‘pays’ for your routine. Just be cautionate to not over-do it.
  • Each team will start establishing a baseline of story points that they can process in a time slot. This is your so-called ‘velocity’. You can easily divide the time over the storypoints and see what the cost would be.  Because your team is focussing on what it would cost in relative terms, instead of fitting deliverance of functionality in a timeslot (which is doomed to fail), you can calculate the cost to analyse ROI versus expected delivery date. You could then also decide to buy from external sources, since you have a good idea what it would cost doing it in-house.
  • Run through the story and write down all steps that need to be done. Now everybody should have a ground level understanding of how to solve this story. Buy a set of scrum-pokercards, count down and let everybody throw down a card. No significant differences? Quickly reach consensus and take the average if no-one objects. Some super high or super low? Let them explain and let the team learn from this perception.

Conclusion

As you might see I’m in huge favor of working in a product oriented environment. This is not always a possibility given your business model and current list of clients. If you would like to go with story points, but your clients are not ready yet, try to do this:

  • find a good size client, preferably one that favors on-time delivery more than super-detailed invoices. You need one or two good sized ones, because this will work best when you allocate one (or preferably multiple) full sprint with a complete team on this.
  • build a business case, show them your intent to deliver more consistently and be willing to invest a bit yourself. You can decrease your own investment over the course of time, but all process changes suffer from inertia so give it some of your own momentum.
  • learn from your first couple of attempts. It is more key to persist in the process than to immediately have the good numbers.
  • make sure you deliver, so make sure you have small stories with almost no uncertainties.
  • Once you have a basic idea of how much the team can do, commit slightly under it and use that room for delivering quality and optimizing your process. This allows you eventually to move the baseline up

You’ve now done what a developer would do. Apply an abstraction layer over business metrics in order for the team to work with their own currency. You’ll have a more productive, more motivated and more reliable team as a result.

Any thoughts? Let me know!

DoD: Distribution of Development

/ timmeeuwissen

For: tech entrepreneurs that are considering the options on where to source their development power from

It’s not an uncommon question. Should I outsource, should I create a distributed environment or should I keep everything (literally) in-house. There comes a time in nearly every company when these options will be (re) considered.

This blog post should shed some light at some possibilities and some of their pros and cons.

The candidates

Local-only

This is when you hire from your own county.

Pros

  • One language that everybody understands
  • You can easily walk up to someone
  • Trust can be established by seeing someone at their spot
  • It’s easy to bond
  • Pair programming and doing coding dojo’s are easy to do
  • You can facilitate a nice entourage and a real sense of being part of something big

Cons

  • You’ll have to reimburse travel cost
  • Hard to find competent or top-class people
  • Because you can easily walk up to someone, you basically disturb them and a lot of effective time can go to waste
  • Being at a spot, doesn’t say you are working or doing that efficiently
  • When you find someone very competent from another country, you’ll have to relocate them

Verdict

It’s easiest to start a company with local people. You can establish a brand, have short (but probably more inefficient) communication and reporting lines and you won’t have to take cultural differences in to account. Because you will have to set-up a facilitating environment anyway, it’s also a good base on which you can start working with interns and juniors so you can really supervise and even micro-manage every now and then (you shouldn’t but we all know it happens when you are still small).

 

Outsourcing

This is where you completely carry over all development to an off-site company.

Pros

  • It’s well known that some outsourced development is cheap as pennies in some countries.
  • You can prototype and work in parallel
  • You can hire for what you need. It’s scalable in that sense.

Cons

  • You might get the features you’ve asked for, but who guarantees the quality and the longevity of the code
  • You will have to meticulously write down every possible expectation of the product you wish for. Don’t assume it will be done for you.
  • There is no intrinsic motivation or personal attachment to the quality of the product
  • You will have to overcome cultural differences and stand firm when someone that works by different rules, laws and ethics disputes your requests or assumed rights.

Verdict

I’ve tried this for a part of an application, but this backfired horribly. It’s hard to gain trust and monitor the quality. You could do this if the product is in example a tool that you just wanted as a prototype to get a better grip on your value proposition. One-time, never look back applications (e.g. apps) get developed like this all the time with good results. Working on a SaaS? Don’t do it, I would say.

 

Truly Distributed

The address is a formality, this is when there is no such thing as an office. Lots of pros and cons on working distributed have been mentioned above, so I’ll try to limit the pros and cons to only that what’s important and different if you work truly distributed

Pros

  • There’s no overhead of physical buildings involved. This money can go directly in your company and its employees
  • you will start judging people on their performance. “Did they do the thing I asked of them” will be more relevant than, “did he work 6 hours or 8, and did he work in the morning or evening”.  This actually ties more in to the nature of people. Attendance is something less relevant than focus.
  • You can work from EVERYWHERE. This is true for the developer, but also for the entrepreneur. Want to travel the world, but still get payed? This is the company to join!

Cons

  • depending on how big the range of time difference is, it can be truly a madhouse to orchestrate everybody in to one virtual room.
  • it’s harder to bond with the team.
  • it’s harder to create a hierarchy or other form of ladder on which the developer can grow. Personal growth must be attended to, it is one of the prime concerns of any developer

Verdict

I have seen and heard companies succeed in this setup. It brings its set of challenges but also benefits. I think that going truly distributed is not something for the fainthearted.  Especially the entrepreneur will have to be the link between all developers. Every part of the process has to be looked at, cleaned, oiled and put back in. Is the documentation there. Is it in proper language. Are all code standards applied. Did he communicate nicely to his peers. etc etc. These are normally things you pass on to your leads and managers, but (especially when you start) should be done by the owner to ensure his company still sails the charted course. I would say that it’s not a natural first choice. You have to have the experience, and maybe it’s easiest to come there by progressively hire more external and bleed out local.

 

Externally integrated

This is when you have the majority of your employees locally, but you also hire dedicated people abroad.

Pros

  • dedicated workers for your company mean they (could or should) feel in line with the company’s goals
  • working with different cultures really broadens your horizon. You’ll become more creative in work and this will reflect to your personal lives. It’s an absolute joy.
  • no cost of commute
  • having this division, enables you to not have all your eggs in one basket. (e.g. internet goes down at HQ, or everybody resents recent management changes and strike or find different jobs)
  • When you hire through an agency, you are able to scale your external development faster.
  • The infrastructure that you should get in place (think of cameras, digital boards, good documentation, communication pipelines etc) is also beneficial for your on-site employees. All of the sudden they can also efficiently work from home
  • All communication should be in a language that everyone understands (most common is English). This future-proofs all documentation, code, etc and prepares your company for being true to serving the World Wide Web (distribute for everyone to read, all over the world).
  • You still have a place to go to, a brand that can be visited

Cons

  • once per X time you will have to gather, take the plane and meet each other for some time and do bonding. This is an expensive undertaking. I have heard from someone who actually has a fully distributed team that the cost is generically about the same as the cost of commute for local people (for a mid-sized company hiring in the same country).
  • Initial setup can be demanding on people and budget.
  • You will have to oblige to the law from wherever you hire. Some laws are really strict and can discourage experimenting with this way of working.

Verdict

When you have the time and means to orchestrate this, I’d most definitely do this. It’s a perfect hybrid form that – even if it fails to work remotely – also greatly benefits your local team.

This will only succeed if you will have someone on the other side willing to understand and work with your company. Be critical about who to hire, especially the first one. But this will also only work if people on the local side bring this person in to all relevant discussions and support whenever this is needed.

Having the mindset and the infrastructure in place, you also create a nice environment for your local employees. They can work from home whenever needed, you remove ‘knowledge lock-ins’ in your team and individual and team performance will go up.

Offshore

(in different time zones)

Extra pros

  • able to run support and development 24/7
  • the world truly is a bigger place than a specific timezone

Extra cons

  • It becomes increasingly harder to communicate when someone lives further
    • daily routines
    • planning deadlines
    • evaluations
    • establishing unity within the company

Nearshore

(in the same timezone)

Extra pros

  • Time of communicating is no issue
  • The locations are generally ‘near’, so cost and time of traveling every once in a while shouldn’t become the main reason to do or not to do it

 

Conclusion

So you’ve probably read it well. The definition of how it’s properly done (DoD), resides in the distribution of development. It might not be low hanging fruit, but the stuff that hangs higher get’s more sun you know ;-). Striving for it might already make the difference. It’s up to you to decide how to implement it for your scenario.

I’m starting an app. What technology should I use?

/ timmeeuwissen / Leave a comment

For: entrepreneurs that need to decide what technology to use for their future app

Mobile first. Everybody does it, wants it, needs it. Simply because your phone’s front
camera probably sees your face more than your spouse. It’s easy, it’s fun and addictive. So usually going for a mobile-first approach seems like a good thing to do.

battle_gloves_sport_boxing.pngIt’s – as an entrepreneur – very hard to decide which technology to use. You could be non-technical, but you still would have to make a well-informed decision on this technical matter and you want what’s best for the company. This blog post attempts to give you some insight (boxing gloves) in what options you have, and how they might affect you in the short and long run.

Progressive web apps

pros

  • The app can be developed in a  well-known stack. Most developers in this world are webdevelopers.
  • Quicker iterations in development, easier to work with each other
  • Quicker iterations on client-side, codebase can pull the latest version ad hoc, instead of having to wait for store approval
  • No store denial, apple google and others cannot curate your app based on its content. Not only the app, but also the update itself doesn’t have to be reconsidered against policies
  • Cross platform, any browser that supports it, on any platform, will be able to show and serve (there’s a caveat here, read for cons later on)
  • Fallback for non-compliant browsers, the browser will simply see a website without the offline benefits
  • It’s really (really) fast
  • The app can be visited by browser, but also installed (become chromeless for a perfect UX. There is no reason your user shouldn’t be able to have the exact experience he or she would have like on native technologies).
  • Not only cross-platform, but also re-usability of components cross-ui (reuse business logic for different experiences on mobile, tablet, desktop, television).
  • Easy to apply lean / agile methodology (determine MVP, test / experiment, pivot or accept and enhance)
  • Forcing of https
    • security against eavesdropping and modifications with proxies
    • security all-throughout the communication platform
    • enablement of https2 (more performance!)
    • more services become active (like GPS) since having them on http would infringe on personal security
  • Progressive compliance with device interfacing rights (e.g. the user will only be asked to allow camera access, when the camera is actually used by the app)
  • All major browser vendors (Google, Microsoft, Firefox, Samsung-web) are actively supporting the adoption of this technology

cons

  • Not all hardware and native functionalities can be accessed as easily as through a native app, though browsers are making a real effort to mitigate this issue. Think of the recent work that’s done in:
    • gps
    • camera
    • push notifications
    • run as a service
    • vibrate
    • multi-touch
    • etc..
  • Not all browsers on mobile fully support this, but it is coming (as spoken of on the google PWA summit 2016 Amsterdam).
    • Safari is currently not actively pursuing PWA, but recently announced they will start making effort (no solid promises there). This probably has everything to do with losing grip on the app ecosystem and possible loss of market share.
  • Some native look and feel for default behavior may differ from the native experience
  • Optimized for 2d web apps. Web Assembly and 3D are coming, but for now one can expect to get highest 3d performance on native.

When to apply

  • Do this if you have an informative app. PWA isn’t really suitable for gaming. It’s not that you can’t, it’s just that usually native apps are better at this or have nicer tools to quickly and effectively approach your goal.
  • Do this when all animations and visual elements are designed and accounted for.
  • Do this when your MVP has best chance of surviving when it’s rolled out on more than one device type

Cordova

Cordova might be a good fallback for PWA on IOS to get maximal coverage on all platforms. Cordova basically shows a webview in an app and loads your web-app from it’s static cache.

Pros

  • It mitigates possible current platform issues, since the entire PWA built app can be wrapped in a native container.
  • There are tonnes of plugins that enable direct usage of hardware or other device features
  • Extendable per operating-system (e.g. when a sync-adapter should be shipped with the app)

Cons

  • Webviews use software rendering and are degraded versions of browsers. Therefore the app will never be as fast as a native or PWA.
  • Publishing to markets comes with all rigidity of publishing to markets e.g.
    • maintain backwards compatibility on all interfacing endpoints, expect users not to update / upgrade
    • slow iterations and bundling of features (release trains to prevent flooding of updates). Also introduced slowness in acceptance by market
    • having accounts for all platforms, compiling against all platforms
  • mandatory compliance with permissions and updates of these policies

When to apply

  • As a fallback wrapper for PWA. I wouldn’t apply this anymore without PWA as foundation t.b.h.

Native technologies (per platform)

Pros

  • fast when operational (usually slower boot speeds than PWA), especially for high performance apps like games
  • when standard device interaction is preferred (like how pulldowns look and how some animations are), this is the best way to go.

Cons

  • you need intricate knowledge on the specific
    • languages
    • development processes
    • device capabilities
    • market rules
    • platform updates
  • codebase is not reusable for other platforms
    • that means that the effort will have to be made twice
    • discrepancies in functionalities between platforms will form
    • you’ll need more people in order to maintain multiple platforms / versions
    • double maintenance, updates will become cumbersome and expensive
  • mandatory installing through appstore, no ‘checking out’ through browser before installing
  • slow iterations in releasing, mandatory release train orchestration
  • mandatory compliance with permissions and updates of these policies

When to apply

  • when developing an MVP, a specific device could be targeted. This can only be done if the success and KPIs of the MVP are not dependent on this factor. Do this only when you are sure enough that the other platform either doesn’t matter, or enough resources will be available to also develop for the other platform
  • when developing for e.g. mobile watch technologies
  • when developing a game

Cross-platform technologies (like xamarin)

Pros

  • one language to rule all app-based platforms

Cons

  • no portability to desktop
  • unfamiliar development process. I’ve never seen many people work on this at the same time
  • harder to find people for, thus creating a strong human dependency (SPOF)
  • there’s a transpilation process. Since native technologies are moving very rapidly, it’s only the question of these technologies can keep up with the pace of multiple OS Vendors.
  • the longevity of native OSses is high, but there is no guarantee on technologies that depend on these OSses.

When to apply

  • When native is preferred over PWA, but cross-device (excluding desktop usage through browser) is really important
  • When a performant application on IOS is key (since the Cordova fallback webview for PWA doesn’t perform that well)
  • When you develop a game and found people that are dedicated and skilled in developing for these technologies.