The fundamental of Health of Objects framework is based on the fact that monitoring health of the object drives efficient and high performance system. We have classified our system into many parts, this enables assigning right ownership so that factors like Scalability, Operability(Health) is taken care as and when you build the system. This classification helps to model the health of the object. Heath of object can be monitored efficiently by following below structure (We are not talking about health of the system).
techmix
Lingering thoughts about technology and software engineering.Design, Scalability,High performance and Internet start-ups are some of the triggers
Wednesday, 11 January 2017
Monday, 3 August 2015
World first Smart Health App - It understands you
Cooey is an smart and simple health manager that capture health vitals, medicines and lab reports. It collects health vitals (from devices or manual entry), stores, analyzes and provide insights of vital signs.Also provides personal health score and health tips.
The smart engine analysis your health vitals and guide you towards better health.
Download @ https://play.google.com/store/apps/details?id=com.biz.health.cooey_app
The smart engine analysis your health vitals and guide you towards better health.
Download @ https://play.google.com/store/apps/details?id=com.biz.health.cooey_app
Saturday, 21 December 2013
Product management in startup
I always loved product management. Thinking about what
others want is such a selfless feeling.
It is not a natural instinct for everyone. It is tough,
human beings are designed to be egoistic.
Product management is like a right drink, alcohol(Technical
skills),water(Business acumen) and ice(User experience).Product management follows S Curve and includes product
development(Microphone as inbound) and product marketing(Speaker as outbound).
Microphone activities include customer research/feedback,
trend analysis, competitive analysis, and development.Speaker activities are feedback, distributing marketing
messages, training sales people and engagement team, brand promotion strategies.
Sitting in room and believing what customer wants didn’t
work well for many companies. This might be the reason why startup became beast
enough to swallow big corporate products.So now let us think about the small boat, does startup
require product management team?Are the co-founders smart enough to figure out what product
needs? The answer can be yes, if one of the co-founders is a product guy!That also means startup needs a product guy.
Product
management should simmer the boundary with other disciples like sales,
development and customer engagement.It needs complete involvement from the whole company so that
right signals are passed to product team.
What it takes to make a great product management in your
startup?
Start from top:
Everyone in the startup should believe that product management is very
important.
Don’t forget gut feelings comes from gut neither brain nor heart.
Even CEO has to listen to what product management team says!This also means all the decision makers should have “product
guy” qualities defined below.
Audience Discovery:
Sometimes startup lose focus because proper audience discovery is not done.
The product management should discover the audience and
understand their needs in depth.Build persona and write down the what they want to do.You have to metamorphous to a “Black Swan” and it needs
practice.
Don’t love your
product: Product management team should not get obsessed. Don’t build a
product you want.Build a product customer wants. This falls back into
Audience discovery and understanding
their needs.
Process is a garbage
collector: In product management focus and methodological approach is very
important.But do you need elaborate process ?. The answer is no, use
process as a garbage collector.Use it as a tool for focus. Whenever you feel some task takes
away your focus add a process to do that.Also add process when you feel anybody should be able to do
the task.
Put the team into
focus: Product guy is the “NO” guy not the “YES”. When bunch of passionate
people brain storm over new feature lot of opinions surfaces.Looking deep into facts and doing the right thing for the
customer is “must” for product management.
Fear of failure:
As a product manager fear of failure can prevent you from doing the right
thing. ”Fixing Fast” is more important than doing it right first time.Build your team around this.
Core Fans:
Identify the core fans of your product. Best way to identify your core fan is
to look at the data you collected about usage.This is as important to remember that this group is the
right audience you discovered. Core fans can really accelerate your brand
value.They are the ambassadors and see value in your product. They
will pay for your product. Core fans also knows how handicapped your product
is.Listen to them.
Continuous feedback:
The importance of feedback is spoken a lot about but how many companies does
make it actionable. And sometimes startup over react to the feedback derailing
the product.
The right balance is the most important job of product
management.
Most of the above point is applicable for all companies.
So what you think is the right thing happening in your
startup w.r.t product management?
Sunday, 3 November 2013
Benefits of Hackathon and how to plan
Next week I am
volunteering for the HackNight
by Microsoft Ventures to represent NowFloats.
I would have loved if the "word" hack means "share your
idea" but unfortunately it means
"to reduce or cut ruthlessly". To etiolate it I decided to take
some effort from my side. Hence sharing some thoughts around Hack days which
can help others.
The "word"
Hackathon was coined by Sun Microsystems around 1999.Now most of the tech
companies have Hackthon (hack day), but why?. Attending hacks makes one look
geeky, get some goodies, a nice T-shirt may be, a photograph with tech magnet,
this is obvious. Beyond this hack days helps techies in many ways. To make most
of the Hackthon preparing well is pre-requisite.
Benefits
of hack day for techies
- Build Next Big What: Hack days are like going to place of worship. It builds a environment in which your thoughts is streamlined by like minded people. This will help you to refine your thoughts/ideas or may be give new direction to your thoughts. Who knows your idea is next big thing! GroupMe and PhoneGap came out of Hackdays! .May be you will meet your "Angel" there.
- Ship it : There is lot of difference between having an idea or coding it and shipping it. In Hackday you have to Ship it. Hackdays helps you understand the importance of shipping the product in given time and the challenges in doing so.
- Gulp More : Learning new technologies, new ways of doing things or other soft skills is also major benefit for techies attending the event.
- Meet people : There are two kind of people whom you will meet in hack-days
- Veterans/Experts/Evangelist in industry : There will be experts attending the event to enable you to do your Hack. Go and talk with them and connect with them during breaks. Also most of the hack-days start/end with interactive session with technical leaders. Students will get chance to meet potential employer.
- Peer Group :You will meet lot of like-minded people. Meet new people and form teams. I am sure there will be a take away for you
- Foot loose : It is a break from your daily routines. It is as good as going for fishing in a nearby lake. Just enjoy it even if you don't catch any fish.
Preparing
for the Hack day event
- Know it all : Understand well what is the intent behind the hack day. Prepare by making notes and how your idea is aligning with the scope and expected output.
- Miniscule project scope: Keep it practical, don't dream of building complicated scenarios. Keep it very simple. First make it work, keep a copy and make it pretty by adding features. If you ask me only one thing that should be taken care then it is this. The concept of MVP revolves around this.
- Learn :Go through the API or Frameworks which you have to use in the hack-day if any. You might have to brush up technologies/framework to use in the hack-day.
- Business value : The judges will ask usually questions regarding business value of the hack. So please prepare for that.
- Preinstall :Preinstall any software you require. Also test any other devices like phone or any hardware your planning to use.
- Reuse :Try to use UI templates, library, your old code, open source or any code from other forums. Nobody is worried about originality of the code in the hack day.
- Hack-mate: Find like-minded people and if possible with slightly varying skills like UI, Design other than coding skills. In hack day everybody in team should code.
- Tummy full: Drink lot of water and eat food. Dehydration can affect your task in hand.
- Connectivity: Usually the venue will get crowed and leads to Wi-Fi connectivity issue. Keep your mobile phone with data connection/data-card/other means as backup.
- Last but not least :Take a print out of your registration notification/email if any so that you don't struggle once you reach the venue.
Beyond
24 hours of sweat:
- Connect with peers and take forward the Idea if you think it can go beyond Hack day. Most big companies got build under small ideas.
- Send e-mail/Add to LinkedIn people you met in the event.
- Add the Hack event to your resume.
- Make a notes of things which you want to learn in detail after the hack day and learn it.
So best of lucks all
the Hackers of the world!
Monday, 14 October 2013
Software development process in Startups
In software development we always start with
“Hello World”. We never start with “ABC”. My little one was watching "fruit
train" today and this made me think about it. Sometimes we jump into “Hello
World” without learning ABC. A dev team for startup is different. How you
build it defines most of the tech startups.
When I thought about process of software development it got outlined as mixture of process and principles. Following is what I discovered.
Agile Process:
The mission statement of our dev team is “Quick with Quality”. We
cannot choose one from either of them. This is also one of the reason “People matters” (See my earlier blog). Recruiting the right people will enable
you achieve both.
Development process makes quality of deliverables
from all the team members agonistic of quality of the people. Common mistakes are avoided by
following process. I think if you have right team with business acumen,
need for strict process reduce drastically. And building that team is what it
takes.
Mostly testing is ignored in early stage start-ups which leads to demo
syndrome* and poor quality. This also leads to team getting randomized with lot
of bug fixes. Following will help to improve quality and efficiency:
Buddies
in team:
1.
Testing each other’s code :Testing improves quality and product
understanding.
2.
Avoid single point of failure: At least two developers knows the code
and configurations. This will come handy for you in many ways in
development and business practice.
Automate: Whenever
you have time automate the testing as much as possible. Start by writing Build
Verification Test (BVT) and move towards Unit Testing(UT). Start
the practice before your code base becomes very large.
Sandbox
environment: It is very important to build a sandbox testing environment. Everything
works in developer’s box**.Virtual environments is means to reduce the cost.
Scrum: Daily
standup meeting are very critical to keep the team focused and achieve the mile
stones. As advocated by Scrum Gurus keep it brief and precise. Keep the sprints
as short as possible. Maintain backlog of the all the requirements and
feedbacks.
Source control, reviews and testing should be mandated even for small teams.
Business validation
process:
In startup the software development team should be integrated to
product, customer engagement and sales team. Business development and software development
can’t be separated. It is very important for leaders to define purpose and principles
of the start-up and make sure that team knows about it. If developer
is doing something other than core business, Stop!. It
doesn't mean stop innovating, it means focus.
When you reduce the barrier between dev and other teams the inevitable side effect are following:
- Team getting randomized by others teams
- Lot of noise-business requirements from other team.
It is very critical for dev leader to make sure that it doesn't go
to this extent.
When it comes to features to implement its a haywire. Pick your right
battle at right time. Pick the "Right"
features for the customer rather than allowing customer to pick the "Right" feature. This task
is very difficult than most of us think, especially if your audience is diverse.
The above doesn't mean you don't listen to customer. Following practice might
help.
- Problem Validation: Does
the problem exist for wide audience.
- Feedback Analysis:
Filter the noise from customer feedback. And prioritize the feedback.
- Product Validation: Do you want to solve the problem now or guide customer towards some existing solution. It might include suggesting your competitor or other solution providers.This is tough for most of us.
In spite of the speed of development, uniformity among different
components, intuitiveness of the eco- system, focus on the problem and
value add should not be derailed.
Don’t develop features which you like. "Disconnect” yourself,
listen to the market and solve the most important problem. After all you’re not
going to use it, your customers are.
Continuous development process:
When you are travelling very fast small mistakes get amplified with time.
Continues feedback and corrective actions doesn't have any substitute. Earlier
you listen to feedback and fix it less catastrophic it will be.
Following helps in continues development and deployment:
Continues deployment: Integrate as often as possible in the
sandbox environment. Let each developer take pride about not breaking the
integration environment. There should be daily continuous deployments to sandbox.
Continuity plan: A startup needs business continuity
plan. It can be simple but there should be a plan.
Enable the team: Once you have right team, enable
the team. We don’t have robots to do software development yet. Come back
to reality. Acknowledge that people make mistakes. They need higher purpose to
work in startup. Allow them to make decisions, allow them to make mistakes,
allow them to interact with business as required. Don't be overprotective about
what you developed from scratch. The team
should run without you …period.
Build Operable system: Build software which gives you continues
feedback from system and business perspective. I have discussed this in detail
earlier.
==============================================================
* Demo syndrome : Your application never works when you go for demo with client or leaders..
** Dev box : Developers computer.
** Dev box : Developers computer.
Labels:
Agile,
Developer,
Development methodology,
devops,
Great Team,
SDLC,
Start up
Location:
Bangalore, Karnataka, India
Thursday, 19 September 2013
Traits of Rock Star Software Engineer
Question: Who you
want to hire for your team?
Answer: A Rock Star Software Engineer.
I am at a juncture where I started thinking about forming
the “A team”. We all know the importance of “P”. Fortunately I have had the privilege
to work with real “Rock Stars”. I pinned all the traits which is common to all
those.
Tagline of great companies reflects what they stand for. Thought
it will be a great Idea to map them to traits of a “Rock Star”.
I’m lovin’ it (McDonald's)
They love what they do. All good programmers are passionate artist.
Artist’s gives utmost importance to the details, perfection and finishing touch.
Takes pride in their code.
Look for good story tellers. When you read their code you feel
like you are reading a story. Story will be very precise and concise. Good
documentation, unit test and following fundamental principles of software
engineering will be quiet natural for them.
Evaluation: Ask how you
will mentor a new joinee into a good software engineer. Ask for importance of
unit test, principles and a practical stories.
Just Do it (Nike)
For Agile working environment we need rock stars who can
just do it. No non-sense. They will find ways to do it rather than ways of not
doing it.
No reinventing the wheel. They will do it the smartest way.
(Design pattern, framework, copy code)
Just do it also means they learn quickly and take tasks to
the finish line.
Evaluation: Ask about
application of patterns and reasons of selecting frameworks. Ask about an experience
of doing something out of comfort zone.
Think Different (Apple)
They have business acumen. They are not code factory. They
know what they do. They will have understanding of the bigger picture. They ask
difficult questions and have to be themselves convinced before doing it. They
think different and come up with simple and innovative solution.
Evaluation: Ask about
projects end to end workflow and business value. Check if he is asking
questions to clarify and does story telling. Give a problem which sounds
complex and look for the approach.
Imagine it Done (Unisys)
Imagine it, consider
it done. Great problem solving skills are essential. Approaching the problem in
a disciplined manner is trait which make them different. No follow-up is required.
They will make sure that the whole team is orchestrated and informed.
Evaluation:
Look at the approach of problem solving. Ask
about deployment and co-ordination with other teams.
Because
You're Worth It (L'Oréal)
Confidence is the
super trait they possess. They knows how much they are worth. You get what you
have paid for. Money is not the only thing which attracts them they believe in something
and they stand for it.
More number of developers
are not equivalent to a Rock star. For that matter sometimes they are irreplaceable.
Evaluation: Is he begging Or He know what he wants.
Confidence comes with knowledge and trust. Don’t confuse with great
communication skills.
Betcha Can't Eat Just One (Lays)
They are curious people. They are aware of latest news in
technology or internals of how things. They learned internals of operating
system because they want to not because they have to. Data structures and
algorithms will be in their blood (or will derive solutions from basic
understanding towards existing principles).
When they don’t know they listen. They will not make others
feel they know everything.
They will have projects which is not related to work. They
always learn, imagine and innovate and do things differently. No complaints
about absence of challenging work.
Evaluation: Ask problem solving
question with application of data structures and algorithms. Observe if they
listens, questions, and disagrees if required. Ask about contribution to open
source or stretch projects or community contributions. (Gist?)
Connecting People (Nokia)
They are not ball of mud. They connect people. Rock stars
believes that by mentoring and helping others you can add more brains and hands
to yours.
They get things done. Again! They are not just code factory.
They also helps software community in some way or other (Blogs, forums, open
source).
But call them for a movie they might not come J
Evaluation: By now you know that.
Conclusion
You will get geeks, nerds.. but they are rare…The Rock stars!
Monday, 9 September 2013
Steps towards software operability
The generic definition for operability in Wikipedia is “Operability is the ability to keep an equipment, a system or a whole industrial installation in a safe and
reliable functioning condition, according to pre-defined operational requirements”.
The definition seems to be applicable to critical application software
deployments also. The clause of “pre-defined operational requirements” either
makes it vague or makes the definition customizable.
An operable
system not only satisfies business functionality for end-user but team behind it.
For example for making an eCommerce site working 24X7 requires a lot of operability
efforts in design to post-deployment phase.
The projects I
worked in past couple of years demanded high operability. This made us think in
different ways of designing and planning. The cost you pay for not having operability
practices in place is very high. It can shoot your company into “Wall of
shame”.
Tackling operability
issues of your project require following acts:
Sell it first: Operability is
inevitable, to which extent depends on the project. Try to get a deeper
understanding of the operability requirements from your previous projects or
similar projects. Prepare well in this phase, tough questions awaits you. What,
How and When should be detailed to evaluate the need, extent, benefit and cost
involved. Sell operability needs of your project to the management, it involves
cost.
If it is an
existing project you might stop here and continue the way you’re executing the
project. Operability is nothing new it always existed and you might already
have things in place. But please read phase two “Get the act together” to make
sure that you didn’t miss anything while planning.
For management
also this is critical phase to understand and justify the cost paid for operability
especially in agile projects.
Get the Act together: Since we are past
the phase 1 you are ready to “Get the act together”. This does not happen as
part of business requirement it needs some extra effort in all the phases of development.
It is strongly recommend to have a separate team which will enforce the principles
of operability, build/customize tools and framework to suit your deployment.
This allows focus, reuse and policing of operability. Having said that separating
functional requirements and operability can be fatal to the project.
Operability team should
improve the process/framework via continuous feedback. The functional team
adopts the operability by infusing it into the business requirements.
Operability
should be part of all phases of Software Development Life Cycle (SDLC).Let us
look at each of the phase from operability perspective.
Design: Define clear milestone goals for
operability. Operability goal can be in following areas
1.
Performance
2.
Scalability
3.
Security
6.
Deployment
7.
Rollback
8.
Monitoring
9.
Reporting
system health
10.
Trouble
shooting
11.
Testing
the points 1-10
All of the above should be present in one form or other in all your
critical projects. If not remember about “Wall of shame”.
Development and Testing: Practically this might be the longest
phase in most projects. As far as operability is concerned this should be the
shortest one. If operability tasks is taking longer go back to operability
team. They need to fix it.
The main intention of this phase is to follow instructions/guidelines and
make sure that next phases doesn’t require human intervention. You should never
lose a chance to automate.
Ensure to log in standardized format across all applications as appropriate
to enable monitoring and troubleshooting in next phase.
Testing for scalability, performance, backward compatibility, rollback has
to execute as planned in previous phases. This is your last chance to avoid
catastrophic failures. Collect as much information as possible and do analysis
of the variations from baseline during performance/stress tests.
Deployment: Deployment should be automated with
rollback plan in place. For high availability you might also consider Business Continuity Plan (BCP).Auditing of the deployment and
production testing will also help to improve the overall operability.
For complex deployment auto provisioning system can be used.It is generally good idea to do dry run before the actual deployment to
make sure that all environment specific attributes are taken care of.
Watch Out!
I would say this
is the most critical stage in operability. In this phase application is
monitored and feedback is given to the system.
Tools required
for this phase can be built or off-the-shelf product can be used. The logs
collected should be stored to do analysis and reports.
Monitoring: Monitoring trending errors, performance
parameters, application parameters and system parameters critical to project
happens in this phase. Servers, Load balancer, Storage, Network, and Switches
are possible candidate for monitoring. Use dashboard/alerts for monitoring the
application.
Troubleshooting: How good you’re in “Get the act together”
phase is usually defined by how fast you’re able to trouble shoot production.
Design to make sure that the exact module which failed is identified
immediately.
Classify the issues identified in this
phase and formulae strict guidelines for the action. Also feedback should be
given to phase 1 and phase 2.
Cloud Computing
Does the above applies to cloud computing?Absolutely.
At least in SaaS I would expect the provider to have a great operablity infrastructure.
Cloud Computing
Does the above applies to cloud computing?Absolutely.
At least in SaaS I would expect the provider to have a great operablity infrastructure.
Take away
Consider operability requirements as a
critical deliverable. The key take away while designing and architecting the
system are.
- Evaluate: The extent of operability
- Specialize: Form a specialized team for operability
- Automate: Remove manual steps
- Feedback: Give actionable feedback to the system
Subscribe to:
Posts (Atom)