Author Archives: eturnti

What is Enterprise Architecture?

Leave a reply

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural / managerial ladder in your organisation can augment your skills and can benefit from this training.

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

How to demo stuff to people ?

Leave a reply

How to demo stuff to people where a sense of how it works is evident and you get a sense of being taken through a journey. Tell it like a story as it is told means you are no longer the guy who is shown how the stuff works but almost get to experience what it means to own or work with that product / tech stuff or gadget. There are many  books being written on this topic such as slideology, presentation patterns and effective presentations and so on. Each of them giving you on what is needed to convey your essence to the consumer of your talk. There is a great deal of learning that Steve Jobs added to this topic and many refer to him as the epitome of someone who told a story and that too a captivating one. No one presented like Steve was the standard. Men of his caliber apart from marketing apple to the world around did in many ways up the standard for presentations and cut down on all the flab that goes with presentations. Carry with you the item that you are going to demo , build a story around it weave it together and the world is the stage for the actor/presenter.

Watched this nice presentation on regular expressions which is always an interesting topic where you can do many many wonderful things with regular expressions. It is skill which can be a great time saver and a productivity tool in software development. You learn this skill to keep your bosses and coworkers happy and most of all solve complex problems and find simple time saving solutions to perhaps writing a tool to automate tests, find the up time of a server, find CPU,memory ,RAM usages and where ever else one can lay their hands on writing scripting to ease the job at hand.

This video had everything neatly explained and is a great demo right from the way the title was named /Reg(exp){2}lained/: Demystifying Regular Expressions. The title style itself is written in a sort of regular expression way , look for the data between / / and replace it with Demystifying Regular Expression. Great presentation and a tool used in the demo written in java script is available at http://leaverou.github.com/regexplained . Tell your story and you no longer have to present it similar to love the work you do and you no longer have to work.

The loser takes it all , failure is so welcome

Leave a reply

failure_not_an_option     

Keeping Failing But do it Fast – Projects / Pet Agendas and Companies 

No option to fail , serious problem. Not failing not quite true anymore ? …This is sounds quite a ridiculous statement more like saying that if you wish to live forever then you should be prepared to die any moment meaning for a cause then you become immortal and then you live forever. The only way to remove a thorn is with a thorn. Does not mean get pricked by a thorn to remove one. What it means is if you the quicker you fail the faster you realize why you failed introspect and move on. Yes inspect why you failed and move on. What this goes on to state in so many things in different facets of life.

Software Projects : You have a mandate from product management on some feature that looks cool in the market and have been asked to roll it out without questioning authority. This then leads teams to prototype it and then check what are the pain points involved before you can say it looks ok to go ahead or not ok. This means you have imposed an increment of work unit which is short time boxed and you come back with your conclusions or state what is possible and not possible in black and white. At times the shiny new thing on the tools available might force one to think that it is the way to product stardom etc. But once you have developers dig their claws into the library or framework it can really reveal whether the framework really promises rapid application development or it is just another cool thing but not so cool when really played around with. Once you get used to failing every now and then you get to learn a new way of handling things in small iterations. This reinforces one to believe that failure is after not all bad in fact we are now more knowledgeable with all our combined failures put together. When someone says we trying out that thing in the market you know what that means and know your way around it . Fail fast is the new world order. It was always like that we never noticed it enough. So all such truth lay hidden reveal themselves to us when we move around try new things and fail , yes fail. Once you know it then the other side of the coin has success embossed on it . The trick is to identify it first and get it right. Know you have failed and that too fast. Do not worry about the project estimates going for a toss , put them with the knowledge that there is going to be 20 % this way that way to it. The message is don’t aim for perfection keep failing and refining.

Pet Projects : Read some where that what ever was in your mind a while ago is now on TV and leaves you thinking that “Oh Oh that was my idea for my pet project” . Do not keep them so bring them out do what you can do to flesh them out bring them to reality else they remain pet projects. This principle also translates it into a fear principle. The guy who has failed first becomes more successful. School dropouts can only create a Microsoft , Facebook or Oracle. Do not keep anything a pet project is the moral here.

Companies : With everything lean and mean a company now unashamedly keeps on revising its mission statement from time to time and does not think twice before changing course many times during the day instead of months or years. Earlier you needed the big consulting companies to say where you are heading and when to turn left and right. Now most companies seem to follow the agile way of doing things and shorter project iterations reveal what we need to do eventually with the product , roadmap etc. So when the failure principle is inculcated into teams , individuals and then the company culture then it becomes easy to drop your opinionated theories and see for yourself in short cycles and tailor your turn around quickly.

What it means that the more agile you are more prone you are to repeated failure. Stay agile welcome failure in leaps and bounds.

Training By eturnti on Aug 10 -11 2013….

Leave a reply

facebook_banner

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural ladder in your organisation can augment your skills can benefit from this training. 

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

Past sessions had the following mix of people attending this training developers,leads, managers,architects, business analysts , consultants working on IT projects, directors and people who are , going to be part of enterprise projects and wanted to know more on how they are managed and executed.

Following are  some of the aspirations of the candidates who attended this training in the past.

1. How are EA projects managed ?

2. How are EA metrics captured , benefits measured and calculated ?

3. What are the EA frameworks and how are they used and applied in principle ?

4. How is this applicable for product development ?

5. Justify the usefulness of EA and measure overall effectiveness of an EA program.

6. Apply these principles to IT and infrastructure projects.

7. Want to lead a team of EA architects and manage an EA project .

8. Usefulness of Togaf and Zachmann and how to apply them to real life projects and derive value. Understand these frameworks and their relevance in setting up an architectural practice.

9. Convince management on architectural best practice and able to contribute to architectural decision making in the organisation.

10. How can we keep EA technology/platform agnostic ?

11. EA and agility where do they mix and match ? Is it really feasible ?

12. How to keep EA projects in iterations well managed and accountable ?

13. Want to know what this buzz EA is all about and what does it mean as I am currently doing architecture work.

Become good at what you are doing, impress your managers,coworkers by attending this course and finally add value to yourself.

Drop a mail at asketurnti[at]eturnti[dot]com to book yourself or click here.

 

 

Testing game is about to start are you ready ?

Leave a reply

areyouready

With the development team’s task over now the task passes on to the QA which is a critical leg in the project. In fact they are the last sentinel on the way to the software trying to make or break its way into the release shipment. While QA could work hard to find and unearth bugs and issues which otherwise might lie hidden under the labyrinth of the product / application. It takes more than just skilled developers doing their best not to plug in errors into the system.While find bugs , code reviews and umpteen number of best practices would ensure that we produce a great piece of functionality or product which is always ready to be shipped the day QA bless it.

Testing a challenge a skill a craft and not something that is easy to do. It is a forte of a chosen few who do their best to go under the hood and look for the spanner left over post the tasks. It is like a doctor who would have performed a successful surgery but left a knife in the patients body. Testing if done right can trap these defects and help plug these issues.

From a tester’s standpoint what would be important ?

1. Many a times a viewpoint/view that he is looking at is not available in document format anywhere in the organisation.

2. No proper handover of what goes into the software if the developer did his stuff and left early to catch the friday nights bus.

3. No diagrams to illustrate what is that has changed in the organization big picture. He is told things like “we have improved security in the system now”. What does this statement leave the tester with unless told what was really introduced as a part of the fix or change.

4.Does he understand what needs to be tested and does he have the tools.

5.Does unit testing/TDD cover what is to be certified. Or do you always need a full product end to end scenario testing.

6. How much of automation do you have in the system ? Are the test cases all automated and effort being made to check if the code coverage is 80% and above. Do we need to up this number ? . Are we getting false positives ?

7. Does our code coverage make us happy whereas there turns out there is always some boundary condition that missed our attention?

8.Do you have a proper architectural artifacts documentation strategy where QA can go look at it and figure out from time to time where the product is heading ? Most often we have it was last updated when we went for that team outing.

9. One of the ways the product gets to have a feel that all is well in the system is a reiteration their documentation and diagrams are updated and understandable by one and all in the system. This mechanism needs to be continuously followed for everyone to sub consciously starting to feel that our mechanisms are what it should be. If not there we fix them when found. Any other feeling here will not reinforce the “right way” among people.

UML is understood by techie crowd whereas we need to have a mechanism for ensuring the business,functional folks and non technical folks also understand the system to touch/feel/breathe the system and own it as much as the developer who put pieces in their. All of these need strong mechanisms for documentation and diagramming/some kind of non ambiguous visual representation of the system/product.

Go choose your diagramming strategy and be ready for any challenges on your way. It is always better to document things even for preparing for agility. On one hand as we always prefer working code than elaborate documentation , it is equally important to have a proper mechanism in place that works for you. That is where the question of just enough comes into play go for just enough documentation and visual representation.

Ultimately software delivery is a close knit game where all need to play their part and not simply passing the baton from one team to another.