середа, 11 квітня 2012 р.

Зачем писать тесты


За что люблю нашу работу, так это за то, что все время сталкиваешься с чем то новым. Не дает скучать, заставляет поддерживать форму. В частности и форму проекта.
В долгосрочной перспективе одной из важнейших характеристик любого программного продукта является его готовность к изменениям. И хорошее, полноценное регрессионное тестирование которое можно провести в разумные сроки – один из ключевых элементов этой готовности.
Разработка тестов требует существенных усилий, накладывает дополнительные требования на инфраструктуру но взамен дает нечто намного более существенное – уверенность в завтрашнем дне. 
А когда ты не боишься измнений, когда ты знаешь как сохранить стабильность твоего кода, ты можешь гораздо меньше беспокоиться о том что может понадобиться завтра и в полной мере реализовать принцип YAGNI (You Aren't Gone Need It) и как следствие сохранять свой код простым. 

вівторок, 18 січня 2011 р.

Who are you, Mr. Architect?


"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
 Antoine de Saint-Exupéry

Software development process overview from roles perspective.

How it happens, in common case? Most important role is  Product Owner because this is the one who understand the problem. Only Product Owner can judge proposed solution and decide will it solve the problem or not and how effective and productive proposed solution will be both in short and long perspective. 
When we have two problems which should be solved by two following roles:
First one - define problem which should be solved to get common understanding of the problem between team players.
Second - define solution for the problem in form, which will be clear enough for Product Owner to judge it. 
To solve first problem we need Business Analyst, who define description of the problem in the form that allow many people share common understanding in a fast and effective way. Importance of this work is quite hard to overestimate. It is easy to imagine what happens when solution is found and implemented for wrong problem. 
Quite often problem description also name Business Requirements. 

It is well known that right question has answer inside itself. The same with right problem description. Good description of the problem already has big part of solution description. So selection of the next role, one who finds solution strongly depends on problem formulation. 

There are many cases when problem description, prepared by Business Analyst defines both business and most important technical requirements, or business requirements can be easily mapped to technical requirements. For this case Engineer can start working with requirements, define, describe and implement technical solution. 

In other cases, when problem description can't be directly mapped to technical requirements and requires selection from different, not obvious, technology options additional analysis required before solution can be defined. As a result solution builds as superposition of choices in technology and business. It is important that the input for making these choices can be obtained only from the business area. This is exactly what Architect is doing - working with business requirements and circumstances to define technical solution.     
  


Between Business Analyst and Engineer. 

"The hardest part of design is deciding what to design."
Fredrick Brooks 

It can looks like Architect it is just Engineer with Business Analyst competences. In some way it can be true but I should say that Architect role is something bigger when just combination of great engineer experience and good analysis competences. The reason is mindset. 
What is in responsibility of Analyst - Define and describe the problem discovered by Owner to be sure that everyone works on the same real problem (one which in Product Owner mind).
What is in responsibility of Engineer - To implement solution for the problem defined by Owner and described by Analyst.
You see gap between this to areas? I see. Who responsible for matching solution and problem? How we can be sure that solution, to be implemented by the Engineer is for the problem, defined by Analyst? Quite often we see solutions which solved absolutely different problem, not the one which Owner has in mind. 
This is the work for Architect. In one of definition of Software Architect it is saying that Architect build a bridge between Business and IT. It sounds quite simple but mean quite complex things. 
Architect need to take into attention much wide picture of business requirements when even Analyst can cover because Analyst must think about the problem as it exists now. Architect need to think about how problem will change during the years and how solution should capable to be changed accordingly. In terms of business Architect not just work on solution itself but also on solution capitalization, i.e. ability to solve problem in the future in effective and productive way.  

When you need an Architect? 
"Good design adds value faster than it adds cost."
- Thomas C. Gale

Quite important question. To be honest it is hard to meet Architect in off-shore software development. I know several but I know much more high qualified engineers who are known experts in particular technologies and it looks like they much more required for industrial programming when Architects. Why it happens? I am not sure. 
You definitely need an Architect when you going to build something conceptually new on the market. Also you probably need Architect work when your business requirements still quite unclear, and you can't be sure what your solution will be tomorrow.


Design in software architecture.
"The hardest part of design is deciding what to design."
Fredrick Brooks


Task of Architect usually is limited by development of solution design, not solution itself. This is quite important point because Architect has two main goals: 
1. Find solution.
2. Clearly describe solution.

Quite often second goal is much more complex when first. Ability to express complex technical ideas in the way clear for non-technical people (or with limited technical competences) is quite rare and valuable. Only when this goal is reached Owner can judge designed solution and define does it solves business problem or not. This point is essence of Architect's work. 

"A chief service of a designer is helping clients discover what they want designed."
Fredrick Brooks


четвер, 9 грудня 2010 р.

Чем занимаются программисты?

Вообщет вопрос может получить вторую премию на конкурсе дурацких вопросов, сразу после вопроса "Как программист пишет программы?". Самое забавное вопрос про Как был задан однажды на полном серьезе руководителем службы рекрутинга большой софтверной компании. Если бы сам не слышал - не поверил бы.
Казалось бы вопросы простые и ответы на них очевидны. Но со временем я понял что ответ который так очевиден для меня, не совпадает с ответом, очевидным для некоторых других :-) товарищей. Поэтому захотелось поделиться своим видением, возможно я в корне ошибаюсь.
В далекие совествкие годы у нашей профессии было название инженер-программист. Потом как то про инжерена забыли поскольку в союзе почти каждый кто не был рабочим или крестьянином был инженером. Ну не считая конечно деятелей культуры и науки, но тех было не так много. А инженеров было много, все кто мог что бы закосить от армии ломились в инженеры. Поэтому когда сверкающий капиталистический мир открылся нам своими сникерсами и бублгумами, и что особенно важно спектрумами и IBM PC инженеры стали ассоциироваться с чертежными досками и маленькой зарплатой, а модно было быть маркетологом или менеджером, и не важно что это означает. Собсвтенно менеджерами модно быть до сих пор.
Тем не менее по сути профессии ничего не поменялось. Однако поменялось понимание, отсюда зачастую люди уверенно считающие себя программистами делают немного не то что надо делать программисту. Что вызывает печаль и недоумение.
В моем понимании суть работы инженера - решать технические проблемы. Способ вторичен.
В этом смысле инженеру-программисту сильно повезло. Он проводит решение от идеи до конечной реализации не полагаясь на рабочих в воплощении решения в жизнь. У большинства проблем может быть много методов решения и в этом и есть элемент творчества инженера - выбрать оптимальное решение из множества возможных.

Почему-то зачастую люди представляющиеся программистами думают что их работа - писать программы. Я уверен что это печальное заблуждение вызванное несовершенством нашей системы образования. Мы решаем проблемы, технические проблемы. Находим решение и описываем его, уточняем, детализируем, пока не получается программа решающая ту самую проблему. Впрочем бывает так что она решает другую проблему, но это уже тема для отдельного разговора.

неділя, 5 грудня 2010 р.

Почему крышки люков - круглые?


В Microsoft часто задают вопрос почему крышки канализационных люков имеют круглую форму. В других компаниях этот вопрос также применяют для оценки сообразительности претендента, да что там я и сам наверно пару раз задавал его на собеседованиях. У этого вопроса есть несколько правильных ответов, самый распространенный - круглая крышка имеет наименьшую площадь при которой крышка не может провалиться в люк.
Сегодня гуляя с собакой как то задумался, неужели экономия и безопасность были исходными причинами выбора круглой формы крышкам колодцев? И попробовал взглянуть на вопрос немного шире...

Колодцы испокон веков копали круглыми. Тут причина очевидна всякому кто когда либо пользовался лопатой - углы квадрата будут постоянно осыпаться, вертикально вырубать грунт проще по кругу вокруг себя. Так его потом и обкладывали камнем или кирпичом.
И теперь спросите себя какой формы должна быть крышка круглого колодца с круглым отверстием? Первый ответ будет - крышка конечно должна быть круглой. Это потом мы подумаем почему и даже возможно поменяем свое мнение под действием других факторов.
Потому что мы инстинктивно предпочитаем симметричные решения. Круглое к круглому, квадратное к квадратному. Причиной такого подхода по моему является пример который нам показывает природа в очень многих своих проявлениях - природа стремится к симметричным решением, наличие симметрии отделяет порядок от хаоса.
Вот вам неожиданный ответ на простой вопрос - круглая форма крышки есть результат борьбы порядка с хаосом.