tag:blogger.com,1999:blog-70867856364663433632024-03-05T01:46:40.362-06:00Software and Other ThingsJane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.comBlogger97125tag:blogger.com,1999:blog-7086785636466343363.post-81309502294964661212019-07-19T14:15:00.002-05:002019-07-27T12:53:30.465-05:00Estimating Sprints aka the problem with Scrum<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBK7JcGhXPNpNNGvGW2osgDnbG21AlXhhvRwkzFmuncGNPfG7cu9N6TFCZTYizDuqmOpljwZdyaIFRluC1_fyj25UccyYpi54Ze3qCz2mb-uQtz7tmu-qFS69woFs4uS136HtLkfMwXfWl/s1600/balanced_rock.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1058" data-original-width="1600" height="263" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBK7JcGhXPNpNNGvGW2osgDnbG21AlXhhvRwkzFmuncGNPfG7cu9N6TFCZTYizDuqmOpljwZdyaIFRluC1_fyj25UccyYpi54Ze3qCz2mb-uQtz7tmu-qFS69woFs4uS136HtLkfMwXfWl/s400/balanced_rock.jpg" width="400" /></a></div>
<br />
<br />
<div class="MsoNormal">
Agile landscape assumes lots of quick churn - requirements grow and shrink, product scope
shifts, technologies are tried on for fit, even delivery platforms seem to be switching
multiple times within project life cycle.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
The time where the team has had a chance to learn enough
about the tech, the requirements, the platform, etc. appears to not come until
much later in the project. In the meantime, while the team figures out the tech
and goes along with the experimentation of what the users will find most
useful, every estimate is a wild guess. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Yet, every two (or one, or three) weeks, there’s the big
Question: what do we pull into this Sprint? <br />
On one hand, there are learnings from past Sprints – some things have gotten
easier, other things were dropped because they could not be done, some architectural
decisions have been made. One the other hand, past Sprint experience shows that
unexpected things invariably come up and slow progress to a crawl. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Then there is reporting. Forward-looking reporting means it
looks bad if the team has not completed everything it has pulled into each Sprint. <span style="mso-spacerun: yes;"> </span>From this perspective, it is better to estimate
conservatively.<span style="mso-spacerun: yes;"> </span>Backward-counting from a
deadline where currently-uncertain features are assumed to be required, and
therefore must be packed into prior Sprints with no room to spare for
dealing with the unexpected. <span style="mso-spacerun: yes;"> </span>There is
very real pressure to load up the Sprint with work that could possibly be all be delivered only under the
best possible scenario. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A less-than-pure approach is flexibility: plan the Sprint
conservatively, with the understanding that the Scrum Master together with
Product Owner will prioritize backlog to pull work into the Sprint if there is
time remaining.<span style="mso-spacerun: yes;"> </span>This is less than ideal
because having more on the plate leads to higher productivity overall – even if
it’s not possible to complete everything.<span style="mso-spacerun: yes;">
</span>Alternatively, a team can choose to plan the Spring aggressively,
pulling more work in, and then reducing the Sprint load if necessary.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>Unfortunately,
this looks really bad from the outside. Well-meaning teams can be penalized for under-delivering relative to an aggressive Sprint forecast - even when that Sprint forecast was deliberately set up to be unrealistic. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Another option to deal with the planning question is to go
back to the world where teams had a lot of scope-platform-design decisions made
up-front, and could provide somewhat reasonable estimates 3-4 Sprints into the
project.<span style="mso-spacerun: yes;"> </span>While those estimates weren’t
exactly right, there was predictability earlier in the project cycle. But that would mean giving up the opportunity to learn and to benefit from new discover as the project is being worked. <o:p></o:p><br />
<br />
<span style="font-family: "trebuchet ms" , sans-serif;">[ This post is a first part of a series. To be continued. ]</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiebZHUA42Ie0Hp_l6qdUXMt8t1BPG1NwJd7vztdb6UdGtuC8Pat8KU0zmqd_9gMXwFIPyGC5nIoY8Q0s1Z8XOXHOWJhxvhabB-E8FJLY43-vF2gbOUytbR1KuTs2gDsQcJBgvYUsjRJzxI/s1600/rock_tower_balance.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1060" data-original-width="1600" height="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiebZHUA42Ie0Hp_l6qdUXMt8t1BPG1NwJd7vztdb6UdGtuC8Pat8KU0zmqd_9gMXwFIPyGC5nIoY8Q0s1Z8XOXHOWJhxvhabB-E8FJLY43-vF2gbOUytbR1KuTs2gDsQcJBgvYUsjRJzxI/s400/rock_tower_balance.jpg" width="400" /></a></div>
<br /></div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-20707881495594929432018-04-27T00:22:00.001-05:002018-04-27T06:52:06.954-05:00Achieving more by blaming less<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjIh_PTfpqkfTPVeJgpBjzJT1zPakoMW8N9HdazEfhoTTWLUP7gEy4xiXYcOtSUNCl9RC5Wqd0QqTQjrZcTntruuB2jMyWvMcZ_JcXtZGBY9oY8dV6nrjDTrIUpGRhnyOp5qx00_gaH5b7/s1600/teamwork-success-motivation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="177" data-original-width="285" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjIh_PTfpqkfTPVeJgpBjzJT1zPakoMW8N9HdazEfhoTTWLUP7gEy4xiXYcOtSUNCl9RC5Wqd0QqTQjrZcTntruuB2jMyWvMcZ_JcXtZGBY9oY8dV6nrjDTrIUpGRhnyOp5qx00_gaH5b7/s400/teamwork-success-motivation.jpg" width="400" /></a></div>
<br />
Complex, consequential and time-sensitive problem-solving is best done in the atmosphere of full transparency. Alleviating fear of blame and sanctions is essential for having an honest conversation, taking social and technical risk, and otherwise focusing on doing valuable and creative work, rather than avoiding negative consequences. Not fearing consequences unleashes creativity and striving for better results, even if it involves risk, is correlated with great success in high-tech.</div>
<div class="MsoNormal">
<br />
<i><b>Sanction-less and blameless are both good, but not identical ideas.</b></i><br />
<br /></div>
<div class="MsoNormal">
<i><b>Sanction-less</b></i> means that those decided to be at fault are not going to be sanctioned – written up, demoted, fired, or otherwise punished. Sanction-less must come from the very top of the organization to be trustworthy, and is fairly clear-cut.<span style="mso-spacerun: yes;"> </span>The promise of “no punishment” can still be broken at any time, but in many organization past history tends to be a reasonably good indicator of the future behavior. <span style="mso-spacerun: yes;"> </span>If the management promises “sanction-less”, and has not levied sanctions for mistakes leading to serious and costly incidents in the past, it is likely that the next incident investigation will adhere to the same policy. </div>
<br />
<div class="MsoNormal">
<i><b>Blameless</b></i> is more complicated. <br />
<br /></div>
<div class="MsoNormal">
Blame is a <a href="http://www.dictionary.com/browse/social-construct" target="_blank">social construct</a>, and involves interpersonal relationships, rather than company policy. Blame can be levied by any person involved in the situation, from the team members to stakeholders to users to bystanders. While blame can be accepted or not by the person who is being blamed, the blame is created by the person or people doing the blaming. It is easy to create blame – all it takes is one person, with any title, role or level of involvement. Once created, blame does not go away. It can slowly fade with time, it can also turn around on the people doing the blaming if it becomes known that the blame was created in error.<span style="mso-spacerun: yes;"> </span>Blame often continues to affect relationships and interactions for a long time, even the relationships that were created after the blame first came into existence.<br />
<br /></div>
<div class="MsoNormal">
Blame is a natural human reaction in response to a negative situation.<span style="mso-spacerun: yes;"> </span>While the goal of dealing with an incident is to recover and, if possible, to make up for lost value, people typically want to know what caused the problem, and who is at fault. <span style="mso-spacerun: yes;"> </span>With wanting to know who is at fault comes the propensity to blame the negativity of the event on that person or people. <br />
<br /></div>
<div class="MsoNormal">
<h3>
<i>Is it possible to get away from the blame, and to create a blameless culture? </i></h3>
<br /></div>
<div class="MsoNormal">
There are a couple of ways.<span style="mso-spacerun: yes;"> </span>One is <i><b>explicit and relentless focus on group responsibility</b></i>, so that personal responsibility is forcibly completely disregarded. While actions are taken by specific people, it is possible to gather all accountability at the team level.<span style="mso-spacerun: yes;"> </span>As causes of the problem are discovered, ignore the name or names attached to the action that created them to the best of your ability, to avoid blaming these people. <span style="mso-spacerun: yes;"> </span><br />
<span style="mso-spacerun: yes;"><br />
</span></div>
<div class="MsoNormal">
The other way to avoid blame is to<b> <i>focus on the future rather than the past</i></b>.<span style="mso-spacerun: yes;"> </span>Do not look for the cause of the problem. Instead, look for a way to solve the problem going forward. <span style="mso-spacerun: yes;"> </span>Work from the solution, rather than the cause, to make changes needed to avoid the same or similar problems in the future. The benefit of this approach is that all the effort goes into resolving the existing situation, rather than discovering and evaluating the past. <br />
<br /></div>
<div class="MsoNormal">
Blameless culture is not easy. Problems can be severe, emotions can run high, and searching for cause is deeply ingrained into our understanding of how work should get done. In addition, our tools are great at keeping logs on who did what and when. <span style="mso-spacerun: yes;"> </span><br />
<span style="mso-spacerun: yes;"><br />
</span></div>
<div class="MsoNormal">
Knowing who caused the problem is synonymous with assigning blame. It is human nature to judge, to evaluate, to critique, and, yes, to blame. It is also human nature to guard against blame-inviting behavior, and not only we try to do well, we also try hard to hide what we did less well. <span style="mso-spacerun: yes;"> </span>A lot of effort and cognitive strain goes into avoiding and escaping blame, however futile.<span style="mso-spacerun: yes;"> </span><br />
<span style="mso-spacerun: yes;"><br />
</span></div>
<div class="MsoNormal">
Achieving blameless culture allows to avoid this waste, and more fully focus on other goals. Consciously working toward minimizing blame promotes healthier relationships, better emotional experience overall and specifically while dealing with severe incidents, and encourages more honesty and transparency. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5ssuliRpyOhJOPrZAekMiaU2OKNYOXWVZ2rc-t4J8bkVFk6R-HctV6V-nE6CvnE6NXqD5TQv81rQjZNZIwE5doyHeWP7qtk8NpnVdp0x_VXaKOTN-9_hxttWrtiJCqy78d_ksVOkMIe1J/s1600/Blame-managers-stressful-workplace-blog-Pamela-Cournoyer.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="533" data-original-width="800" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5ssuliRpyOhJOPrZAekMiaU2OKNYOXWVZ2rc-t4J8bkVFk6R-HctV6V-nE6CvnE6NXqD5TQv81rQjZNZIwE5doyHeWP7qtk8NpnVdp0x_VXaKOTN-9_hxttWrtiJCqy78d_ksVOkMIe1J/s400/Blame-managers-stressful-workplace-blog-Pamela-Cournoyer.jpg" width="400" /></a></div>
<br /></div>
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-30091940990262832662017-12-20T22:09:00.001-06:002017-12-20T22:09:40.356-06:00Achieving success<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigdPsGl8kg4JARtHL4M0uwREOdA2-utH8VWTRbZIY5_sMUVmgOkEOve7tGd7mSMoD8d_8WJj8tRBRjpRly2C4rel60jSwzY51jD2gOIO8YibH2pFSNXl5szN_sqvq67kmmJlzzb4ojGsVd/s1600/ad127167895sochi-russia-f.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1115" data-original-width="1600" height="277" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigdPsGl8kg4JARtHL4M0uwREOdA2-utH8VWTRbZIY5_sMUVmgOkEOve7tGd7mSMoD8d_8WJj8tRBRjpRly2C4rel60jSwzY51jD2gOIO8YibH2pFSNXl5szN_sqvq67kmmJlzzb4ojGsVd/s400/ad127167895sochi-russia-f.jpg" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
When considering performance, there is typically more focus
on failure than there is on success. Failures are often noticeable,
well-remembered one-time events that generate high emotions and can affect many
people. There is the idea that teams
learn from our mistakes and failures, and that in order to improve teams must
fail publicly and painfully. It is believed that significant successes must
somehow be rooted in overcoming past misfortunes and failures. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Success can be loud and come with a lot of fanfare as well,
but the fanfare of success tends to fade faster. New challenges pop up and emotions go away quickly
because the team must get back to work, as success tends to bring in more work and generate additional challenges. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
As a result, success appears to play a smaller role in
overall evaluation than failure. That is
both unfortunate and counter-productive. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It is unfortunate, because failures are not necessarily what
makes us learn and improve going forward. While occasionally there is learning
that is an outcome of failure, the same learning can also happen without
experiencing the fail. A lot of failures
are unavoidable, but nevertheless result in blame (or self-blame) and reduce
motivation.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Focus on failures is also counter-productive, because
failure is hardly ever the enemy. Failures come from experiments, from aspiring
to reach farther, from ambition. Statistically,
it takes a number of failures to achieve significant success. Without these failures, the success is either
impossible, or a lot less likely. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Success is not the opposite of failure, rather, it is a significantly
different happening. Success often comes
with more work and more responsibility, creates additional challenges, and pushes
the team to work harder. Success
requires active learning and deliberate practice, and there is a need to learn
still more to handle challenges brought on by the achievement. Success encourages ambition and
experimenting, and boosts motivation.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Success is the main driver of future success. It is time to
focus more on success, and less on failure, when considering team performance. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj71Sm8BtufSgucsOXr4bfH9NWDKZoq3y5zKGGSFYpLAXgxSVVcQqFSarRts79ct1npMLMNCH28T9shaTL6RupEreT-r4Mbjj2-uhBQy-s4fdEFKMzSHLxiwBKRVHf0soTL8bl4mrAJCQbh/s1600/iceskate-champions.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="706" data-original-width="1000" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj71Sm8BtufSgucsOXr4bfH9NWDKZoq3y5zKGGSFYpLAXgxSVVcQqFSarRts79ct1npMLMNCH28T9shaTL6RupEreT-r4Mbjj2-uhBQy-s4fdEFKMzSHLxiwBKRVHf0soTL8bl4mrAJCQbh/s320/iceskate-champions.jpg" width="320" /></a></div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-8005843619146697282017-09-25T16:41:00.002-05:002017-09-25T16:41:27.821-05:00Deciding the architecture<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIyjhM3_59GH62jAvGIvrd0r2Jovl1DvoA7j18Y19ouCkLRMWV6xtooA1S06NlahcszK1pQuaqFSkoXP66OqtIqHpw7_WUnlybVJg9SrsrDETnZX7tK4WTX8fTflEI34Kl-FL59TFrMXZ-/s1600/Sydney-Opera-House-Sails.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="635" data-original-width="1600" height="157" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIyjhM3_59GH62jAvGIvrd0r2Jovl1DvoA7j18Y19ouCkLRMWV6xtooA1S06NlahcszK1pQuaqFSkoXP66OqtIqHpw7_WUnlybVJg9SrsrDETnZX7tK4WTX8fTflEI34Kl-FL59TFrMXZ-/s400/Sydney-Opera-House-Sails.jpg" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Agile project starts by gathering an Agile team, deciding on a project and specific deliverables to be built first, and setting up the needed infrastructure. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
But before the team goes about creating the infrastructure, several questions about the system architecture need to be addressed. What infrastructure will be needed, and what skills the team must have, greatly depends on the proposed system architecture and technology stack. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Who decides system architecture is the “elephant in the room” issue of Agile projects. Many smaller design decisions will happily “emerge” as the team goes through the daily work of building the project iteration after iteration. Still, there is a number of large-scale, long-lasting choices about system architecture, that must be decided at the start of the project, when relatively little is known and the team has the least amount of experience on the project. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Who should be making these decisions? The typical answer appears to be The Architect, someone high up in the ivory tower, someone who makes no mistakes by producing little to none tangible, and thus imperfect, results. Sometimes that person is very good, and in other cases they just get by. As it turns out, making the very best initial architectural decisions for a given project is not particularly important for the project's success, and making passable architectural decisions is fairly easy and fool-proof. </div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
List of <a href="https://medium.com/towards-data-science/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013" target="_blank">common architectural patterns</a> is very small, and almost all projects fit nicely into that tiny set. Even if an inappropriate pattern is picked, the team will be fighting, and winning, over the inappropriate pattern to create a working implementation. If the system becomes successful despite poorly designed architecture, and fighting the system setup becomes a serious obstacle to evolving the product, it will get re-written with a less inappropriate architecture shortly.<br />
<br /></div>
<div class="MsoNormal">
P.S. </div>
<div class="MsoNormal">
<i>Sydney Opera House is one of the most beautiful and distinctive buildings in the world. Its architecture went through a dozen iterations of design, and the finished structure exhibits terrible acoustics - a big problem for an opera house and performance venue. The building took 10 years longer than planned, and went 1,357% over budget. Of course, the project was, and still is, a resounding success.</i></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEga3y3NxFCCSnb7062L2-ZuwNC1LrZkxYyt22RNuVdhCtvlcN50cFkLDP8tqCCWlwV8uzveuzb9fEpjle1TNTu5UhO0zuaBF1bazF47TgmarGofwpWeOhYNZB4MFnb5Dr562bcDP2te0ACu/s1600/flowchart-madness.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="880" data-original-width="1600" height="220" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEga3y3NxFCCSnb7062L2-ZuwNC1LrZkxYyt22RNuVdhCtvlcN50cFkLDP8tqCCWlwV8uzveuzb9fEpjle1TNTu5UhO0zuaBF1bazF47TgmarGofwpWeOhYNZB4MFnb5Dr562bcDP2te0ACu/s400/flowchart-madness.jpeg" width="400" /></a></div>
<div class="MsoNormal">
<br />
<br />
<br />
<o:p></o:p></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com1tag:blogger.com,1999:blog-7086785636466343363.post-40623916034943804412017-07-30T22:22:00.002-05:002017-07-30T22:35:50.404-05:00Scrum as a series of feedback cycles<div class="MsoNormal" style="margin-left: .25in;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGw5NxuvbtP9I8jCFzgBN_0sJnkrtXj_MLHrAYdNOwqti0RErSrqBoZ5_KpnNPQjmhhSVNXklBKo5pE9qb4yo2LRNO9dKQoJ-cHRQ8_KYxxnZT-i2PYjf1d-AxhyhJoc0v3TBVtFHtxfoB/s1600/scrum2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="405" data-original-width="640" height="252" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGw5NxuvbtP9I8jCFzgBN_0sJnkrtXj_MLHrAYdNOwqti0RErSrqBoZ5_KpnNPQjmhhSVNXklBKo5pE9qb4yo2LRNO9dKQoJ-cHRQ8_KYxxnZT-i2PYjf1d-AxhyhJoc0v3TBVtFHtxfoB/s400/scrum2.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<h3>
<ul style="font-size: 18.72px;">
<li><span style="font-weight: normal;">Daily scrum: every 24 hours, within the Scrum team. Feedback on technical details.</span></li>
</ul>
<ul style="font-size: 18.72px;">
<li><span style="font-weight: normal;">Sprint review: every 1 to 3 weeks, within the product team. Feedback on requirements, features delivered, and implementation details.</span></li>
</ul>
<ul style="font-size: 18.72px;">
<li><span style="font-weight: normal;">Retro: every 1 to 3 weeks, or, better yet, on as-needed basis, within the Scrum team. Feedback on communication, processes, resources.</span></li>
</ul>
<ul style="font-size: 18.72px;">
<li><span style="font-weight: normal;">Backlog grooming: every 1-2 days or even more often, within the product team. Feedback on features delivered, technical details communicated, and user feedback.</span></li>
</ul>
<ul style="font-size: 18.72px;">
<li><span style="font-weight: normal;">Sprint planning: <span style="color: red;">not a feedback cycle on anything… why is it a part of Scrum?</span></span></li>
</ul>
</h3>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaOR26LBpoEHhvmgysLQq5ezXEmphbpRa9DaF7eJzBGOTkaHwvYV7k4Dq5cod8oBEG5kyAwf8JcjJ-MjzRo3aVwzQPBuBbM3J7a9m5OdAHqbET8vIywwMu93WxI6ii71nsfRMKL5V7v-zD/s1600/feedback-cycle.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: justify;"><img border="0" data-original-height="423" data-original-width="600" height="282" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaOR26LBpoEHhvmgysLQq5ezXEmphbpRa9DaF7eJzBGOTkaHwvYV7k4Dq5cod8oBEG5kyAwf8JcjJ-MjzRo3aVwzQPBuBbM3J7a9m5OdAHqbET8vIywwMu93WxI6ii71nsfRMKL5V7v-zD/s400/feedback-cycle.png" width="400" /></a></div>
<div>
<br /></div>
<o:p></o:p><br />
<div class="MsoNormal" style="margin-left: .25in;">
<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: .25in;">
<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: .25in;">
<o:p></o:p></div>
<br />
<div class="MsoNormal" style="margin-left: .25in;">
<o:p></o:p></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-28026957762553870742017-07-02T20:52:00.001-05:002017-07-02T20:52:12.683-05:00A key to the kingdom<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiODD7K1_30e0rdPjoZbdrEkOVu8qJnwfLUBRNG2jZ0zHvNxre0lznn-1oDp0Sku-F_VT4Ipl_3ZJyY5HVdiZTBZvH5vFX0Zl1VGFHIJVR4EaGXSTElzjb9RCIlocdKtk-QsZTL-G0lGqUR/s1600/iceberg.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="666" data-original-width="1000" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiODD7K1_30e0rdPjoZbdrEkOVu8qJnwfLUBRNG2jZ0zHvNxre0lznn-1oDp0Sku-F_VT4Ipl_3ZJyY5HVdiZTBZvH5vFX0Zl1VGFHIJVR4EaGXSTElzjb9RCIlocdKtk-QsZTL-G0lGqUR/s400/iceberg.jpeg" width="400" /></a></div>
<br />
Agile talks about emergent architecture and building vertical slices of functionality. It is typically understood that all efforts must go toward creating valuable user-facing pieces, as opposed to delivering software layers that cannot be used until all other layers are in place. Unfortunately, this approach is often taken as “all we need is the visible parts”, i.e. the parts that the user gets to see and click on, or that push the data to be displayed.<br />
<br />
When I first encountered a large DB supporting a well-used, living application with no indexes or foreign keys, I thought it was a rare oversight. Then I encountered a few more database setups just like it, with large and heavily used tables and relationships, but neither indexes nor keys defined. In all cases, users were complaining about slow response times, and administrators remembered more than one instance of the application becoming non-responsive under heavy load as DB requests timed out en masse.<br />
<br />
Other developers I talked to also mentioned that they worked with reasonably large DBs that were missing indexes and foreign keys. A number of people, working in different companies on unrelated projects, mentioned that their engineering managers or software architects absolutely refused all suggestions to create even primary keys on tables “since nobody sees them anyway”. Several developers talked about applications being re-implemented, in part, because of poor response times caused by frequent timeouts of DB requests.<br />
<br />
Vertical slices of user-visible functionality must include “the plumbing” that allows the application to handle the expected load. “Emergent architecture” is not complete without at least basic considerations of technical quality. A project cannot succeed without understanding what it takes to deliver user value in a production situation – and that typically includes multiple users working simultaneously. Building in proper DB infrastructure is a simple example of such considerations, the work that is not visible but nevertheless valuable to the user.<br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi61fJubcq-M514U_kkM7fT6Tnz7rtRgFkkf_-V8hpX87gxZjGfimih_DR7cUkvylK-dDfuas_F62hmAIXg7v30bhViHiIYfUwEO2OZNdkBlu5HUESoUHmlDJovGVVJMmfx0lylBwtOwAOb/s1600/database-index-cloud.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="450" data-original-width="410" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi61fJubcq-M514U_kkM7fT6Tnz7rtRgFkkf_-V8hpX87gxZjGfimih_DR7cUkvylK-dDfuas_F62hmAIXg7v30bhViHiIYfUwEO2OZNdkBlu5HUESoUHmlDJovGVVJMmfx0lylBwtOwAOb/s1600/database-index-cloud.jpg" /></a></div>
<div>
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-25331157329715630922017-06-16T14:33:00.003-05:002017-06-16T14:33:45.064-05:00When the math is off<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><span style="margin-left: auto; margin-right: auto;"><a href="http://minimaxir.com/2016/07/stack-overflow/" target="_blank"><img border="0" data-original-height="750" data-original-width="1200" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0-DxUk0EgKW9zedFf2uVcn0EEv2GjWHJAamRfUtaKXIHWN02qxP5sK7Gc_amfifEBpwwBWuxy1qzeizNnfb0b9HuD-6Re2pDj_d7_V5EInSKF6zhqH7Ln6SgEt6I_PFbWIGxiIczOay8N/s400/so-programming-0.png" width="400" /></a></span></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://minimaxir.com/2016/07/stack-overflow/" target="_blank">How Developers Rate Their Own Programming SkillsMax Woolf @minimaxir</a></td></tr>
</tbody></table>
<br />
Here is a common interview question that is typically gets asked in interviews:<br />
"Please rate yourself in your best skill, on a scale of 1 to 10, where 5 is average."<br />
<br />
The answers most often are between 7 and 9.5 inclusive, with an occasional 10.<br />
Lets consider what that means.<br />
<br />
Skills and ability to contribute have been shown to be distributed according to a <a href="https://en.wikipedia.org/wiki/Pareto_principle" target="_blank">Pareto Principle</a>: 20% of the population possess 80% of the skills and deliver 80% of the results. Suppose, it is a Pareto distribution with the slope of 1, and a minimum skill value of 1. There is no max value for the true Pareto distribution, but the way developers are asked to use the scale, the max value is set at 10.<br />
<br />
A few runs on <a href="http://www.math.uah.edu/stat/apps/SpecialSimulation.html" target="_blank">University of Alabama in Huntsville Special Distribution Simulator</a> show that for a 1000-point simulation the mean is in the 7-9 range. So far so good. <br />
<br />
However, the randomly generated values have no set maximum, and can go well above 10. Even a few higher values in a large set skew the mean significantly. To get back to the allowed range of values 1 through 10, replace all values in the 1000-point dataset, that are above maximum allowed value of 10, with 10.5. The average drops down to ~4. The median is ~2, i.e. half the data points have values of less than 2.<br />
<br />
That contradicts the initial question, which sets 5 as being the average. A distribution of skills is likely to have an average level skewing lower than half the range. In this example of modeling skill distribution with a Pareto distribution 1,1 - way lower, at the mean value of 2. More importantly, it raises the question on how well the interviewers understand the question they are asking the candidates.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://onlinelibrary.wiley.com/doi/10.1111/j.1744-6570.2011.01239.x/full" style="margin-left: auto; margin-right: auto;" target="_blank"><img border="0" data-original-height="555" data-original-width="913" height="242" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6_W3QGstLId_19Urc5T4KPuIWO3RmrvhdZUK4ftW0fyudAlbtzk3xICo5UIZtYZwzdae2DEibraDBVjE1KrmfjJbfz-9zhdGTa8oGUrxbVLhgiarR_iLe-mTwOJHDlAnjLkD9b5zfhxSA/s400/powergroup.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td class="tr-caption" style="font-size: 12.8px;"><span style="font-size: 12.8px;">"The best and the rest: Revising the norm of normality of individual performance." <br />
by Ernesto'Boyle Jr., Herman Aguinis</span></td></tr>
</tbody></table>
</td></tr>
</tbody></table>
<br />All of the above is just a long way of saying that when a typical candidate for a position rates himself in response to the question, they are, so to speak, gaming the situation. <br />
<br />
The more interesting observation is that not only the question is asked regularly, by many, if not most, developers acting in the interviewer capacity. The answer is taken seriously and can influence how the interview proceeds, as well as the outcome. People with higher self-rating (those claiming to be above 8) are more likely to be hired and promoted.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwnXZoeN9k5rZFWwEtChws0suTrHAO9psQ_Qk5mDzUCK95JmvrLQF1iVYhtr5GGBOa4BfVAG0hYMgsApkm-yXvKjHvDfgwZ5aj7acWDBuSC7Phx-TKBQbzCSf2NSOaVpdBYxM0OzXYcSCf/s1600/software-developer-success.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="300" data-original-width="400" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwnXZoeN9k5rZFWwEtChws0suTrHAO9psQ_Qk5mDzUCK95JmvrLQF1iVYhtr5GGBOa4BfVAG0hYMgsApkm-yXvKjHvDfgwZ5aj7acWDBuSC7Phx-TKBQbzCSf2NSOaVpdBYxM0OzXYcSCf/s320/software-developer-success.jpg" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-10303694356784757632017-06-07T09:56:00.004-05:002017-06-07T09:56:47.012-05:00Honest or nice<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU-CQKFHxA-lqipYX2RztO-tIDWGDPUZfnZazHii3bzq1kcIiHdewH-QcxJqIqYts8iou1GdsTCP3vy_Vnpt2HEzS7Gepawd_HCnx2y7IcA2nhC8-53Xkx321vn4tt1I-bkBruxUAQuUbU/s1600/CodeReview-HonestOrNice.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="488" data-original-width="719" height="271" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU-CQKFHxA-lqipYX2RztO-tIDWGDPUZfnZazHii3bzq1kcIiHdewH-QcxJqIqYts8iou1GdsTCP3vy_Vnpt2HEzS7Gepawd_HCnx2y7IcA2nhC8-53Xkx321vn4tt1I-bkBruxUAQuUbU/s400/CodeReview-HonestOrNice.PNG" width="400" /></a></div>
<br />
We have a lot of conversations how we could do better. Deliver more functionality and prettier UI, cause fewer bugs, have more fun while we put in more hours. Write better code, and pay back the technical debt.<br />
<br />
At <a href="http://200ok.us/" target="_blank">200OK</a> web professional's conference we were talking about <a href="https://www.slideshare.net/jprusakova/effective-codereview-color" target="_blank">code review</a> – the part of software development process where developers and architects get together to consider other people’s code with the purpose of offering critique. <br />
<br />
Having one’s code subject to review is terrifying for many people, and liberating for others. It is also necessary, for most of the code outside of personal projects. But how we are going about doing the review can make a huge difference for all involved.<br />
<br />
There comes a scary idea of being nice to the people one works with. Genuinely, authentically nice – actually wish them to be successful, be willing to put effort in helping them, and talking about that.<br />
Here are some suggestions:<br />
<br />
<ul>
<li>Start code reviews with saying to your fellow developers that the work they have done toward the team’s goal is noticed and appreciated.</li>
<li>Call out good code – clearly expressed logic, fitting patterns, relevant abstractions, meaningful naming. </li>
<li>Notice good intentions, as expressed in code, even if the result is less than perfect. That includes error handling, code broken down into smaller modules, attempts at unit tests. </li>
<li>Finally, suggest changes as you would to a very senior, very experienced colleague – share knowledge while acknowledging their wisdom and understanding. Everyone needs to learn, and everyone deserves to learn in a respectful, cooperative environment. </li>
</ul>
<br />
Being actively and explicitly nice, yet honest, to one’s teammates does a few interesting things to overall team dynamic. More people speak up and offer ideas. Jerks become more visible. More conflict bubbles up and out, and leads to a healthy discussion. <br />
<br />
<a href="https://qz.com/625870/after-years-of-intensive-analysis-google-discovers-the-key-to-good-teamwork-is-being-nice/" target="_blank">It may even lead to delivering more value, while enjoying working together more.</a><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0VeEg5ztUSNpn69YVh_OoehDZ5H3ciE0HLOaYtV5YxIbjd_GWNS9_8z6HDEUBhmY-gzQnrhyphenhyphenI-19FfS66PS3fuulzCZOlF2r1zbuB_gIvWhStiRSb6zwna11fvq3kfMFQnb9aCZS_C7E6/s1600/lego-teamWork.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="375" data-original-width="500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0VeEg5ztUSNpn69YVh_OoehDZ5H3ciE0HLOaYtV5YxIbjd_GWNS9_8z6HDEUBhmY-gzQnrhyphenhyphenI-19FfS66PS3fuulzCZOlF2r1zbuB_gIvWhStiRSb6zwna11fvq3kfMFQnb9aCZS_C7E6/s1600/lego-teamWork.jpg" /></a></div>
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-3624191002287053672017-03-13T22:58:00.000-05:002017-03-13T22:58:01.611-05:00Brown-field development<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><span style="margin-left: auto; margin-right: auto;"><a href="http://unemployedprogrammer.blogspot.com/2009/03/rpg-evolving-programming-language.html" target="_blank"><img border="0" height="325" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigA865RQqyZyzpNDg6Ik_4kzkfaS9P6SrOpC0clvlZbDcEMLJXrlaLSfKA3MDiT-EJKkyOTvX1VHO8iri4bl6rFVjUiJiQ8HMBzgZyLfJlqisy2ZcwUJeEWT2TGePvJWqLq1t4NLwt4xR9/s400/rpg+for+loop+source.jpg" width="400" /></a></span></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Image Copyright <a href="http://unemployedprogrammer.blogspot.com/2009/03/rpg-evolving-programming-language.html" target="_blank">@ Robert Brooklyn http://unemployedprogrammer.blogspot.com/</a></td></tr>
</tbody></table>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Developers often complain about working on legacy code base. “Green field” development, i.e. writing
brand-new systems where no code existed before, is relatively rare. Most
software development work happens in the midst of the pre-existing and often
relatively old coding. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Why is so much work being done on legacy projects? If people
prefer to work on new code, and people in software development industry often
get what they want – why isn’t there more of brand-new software projects? After all, software developers nowadays get
shiny offices with nap pods and gourmet catering, free laundry services and massages
on-site. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It is <a href="https://smallbiztrends.com/2005/07/business-failure-rates-highest-in.html" target="_blank">well-documented</a> that <a href="https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm" target="_blank">most of tech startups fail</a>. Most ideas do not lead to
sufficient ROI and good business value. A lot of software projects get done [to
some degree] and then thrown away, because they did not turn out to be viable
enough to keep investing in. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So what is left is a select few projects that turned out to
be spectacular successes: profitable enough to keep using and getting business
value from for a good long time. Organizations choose to continue to invest in these projects because
older systems offer continuous income and a well-known ROI based on past
history. While these projects are
relatively rare, they tend to be large: small projects grow over time, and over
80% of investment in a software system happens after the project is declared
done and enters maintenance mode.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Most of the non-startup development happens on the large,
hairy, hugely successful projects with boring names and scrappy old interfaces.
The code can be old, but the system is brilliant – it survived the competition
with all other competing projects in its business space. This is where the ROI and the business value
are. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<o:p>The offices may be getting nicer and brighter, but we are likely to continue working on in the deep-brown for the foreseeable future. </o:p></div>
<div class="MsoNormal">
<o:p><br /></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEillBiKUeSuwYQC1ctLTYZVo5GJCz5s1wj05JdF7vK020_H5DG15-dysgDyimgXB6s0emD4I2TDf35WX6HmLR2_f-kBv_t6gsLevm3EO_5gk7-UipMbLuhuI6b63MIVRe4pjwJA__BvLaXD/s1600/mv_office_-_10.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="235" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEillBiKUeSuwYQC1ctLTYZVo5GJCz5s1wj05JdF7vK020_H5DG15-dysgDyimgXB6s0emD4I2TDf35WX6HmLR2_f-kBv_t6gsLevm3EO_5gk7-UipMbLuhuI6b63MIVRe4pjwJA__BvLaXD/s400/mv_office_-_10.jpg" width="400" /></a></div>
<div class="MsoNormal">
<o:p><br /></o:p></div>
<div class="MsoNormal">
<br /></div>
<br />
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-53575290721226109642016-12-21T22:37:00.001-06:002016-12-21T22:37:12.044-06:00The bug of security theater <div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwszco9BdztkRDjGiuk6AFgBPv_SV5ee2slvC3QyFudZ7q6LYsyb0slsO_lnjkLZQpc_RIeG7mvVugbNYIZ4xLgMkD4dU0_2bR_a4nNw3FHIao417xd7Xv18BAjnDSSr4-NkMptlHQBlb9/s1600/internet-security-privacy-6797.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="223" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwszco9BdztkRDjGiuk6AFgBPv_SV5ee2slvC3QyFudZ7q6LYsyb0slsO_lnjkLZQpc_RIeG7mvVugbNYIZ4xLgMkD4dU0_2bR_a4nNw3FHIao417xd7Xv18BAjnDSSr4-NkMptlHQBlb9/s400/internet-security-privacy-6797.jpg" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It seems like the Internet and web-based services have been
around forever and work well – from anywhere, just open up a browser on any
device that supports Internet browsers. Well, at the end of 2016, there is a new bug going around,
preventing many different services from serving. The bug of <a href="https://en.wikipedia.org/wiki/Security_theater" target="_blank">security theater</a>.</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
After <a href="https://www.identityforce.com/blog/2016-data-breaches" target="_blank">many a security breach</a>, billions of records exposed or
stolen, millions of people affected in some serious or minuscule or unknown
ways, the providers have learned that security matters. However, security
breaches are still relatively rare, unsystematic, and often caused by an ‘oops’
– some singular event that wasn’t supposed to happen, like operator error. In many cases, there is simply not enough
information how to prevent the break-ins and unwanted exposure or loss of data.
In other cases, providers may be able to do somewhat better – but at the great
expense of re-training staff, updating and enforcing stricter policies, and re-working
technical systems. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Still, there is something that is relatively cheap and easy to
do, and improves security – at least in the eyes of users and media. Security theater is commonly show-cased in
<a href="https://techcrunch.com/2016/08/13/its-time-to-publicly-shame-united-airlines-so-called-online-security/" target="_blank">the user interface</a>. Many-factor authentication, secure codes sent by email or
text message or by audio in a phone call, highly sophisticated personal and
public questions going back many years for the users to answer – all for the
privilege of accessing the same old web-based email account. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Many providers are <a href="http://www.komando.com/tips/289523/5-details-facebook-asks-for-that-you-shouldnt-give/all" target="_blank">requesting a smart phone#</a> to authenticate
against, which is good for them – more data, but bad for us – more advertising
phone calls. Many providers require a
live exchange of data over the phone or email before allowing access, which is
hardly good for them, and definitely bad for us – the wait times are often
unreasonable. Still others insist on
following up online communication with a phone call – which is bad for
everybody, because if we wanted to communicate by phone, we would not bother
with online access at all. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<br />
<div class="MsoNormal">
<a href="http://www.govexec.com/magazine/features/2007/08/security-theater/24994/" target="_blank">Security is different from security theater.</a> Security is hard, and should enable us to do
more business. Security theater is cheap, generates false sense of being
protected (and very real frustrations), and prevents us from doing things we
want to do. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx5zyaYcqq2_me051CZEr0U1xsW_pj6ZbCs_VKGPJ5t212bHf5NRKbz00FI3Jed80RWz6ccQJEfzNwIhLKGC5Lm5X4J3DPB_zpE3eyuJVmZ2j0KCbdlMopNGXVZWp5YJ449V-A0BGnikwP/s1600/pink-crocodile-leather-001.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx5zyaYcqq2_me051CZEr0U1xsW_pj6ZbCs_VKGPJ5t212bHf5NRKbz00FI3Jed80RWz6ccQJEfzNwIhLKGC5Lm5X4J3DPB_zpE3eyuJVmZ2j0KCbdlMopNGXVZWp5YJ449V-A0BGnikwP/s400/pink-crocodile-leather-001.jpg" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-27534424608459058942016-12-12T17:07:00.002-06:002016-12-12T17:07:29.945-06:00Conversations on diversity<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhjHmYGzblgfFCteHD_WZBBZtPRHMQNsT3UkCC6uM3kACPV93XbfE2BZlHhQyVHCJz8YaydHzTqlLZO8R6fMY9JZ9V55f_-T2wSbpMru1Y2JSXyNVE0rIZCNr1lnzWi22qtzJ4MmZwqjEU/s1600/ThisIsNotMyBoyfriendsComputer.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhjHmYGzblgfFCteHD_WZBBZtPRHMQNsT3UkCC6uM3kACPV93XbfE2BZlHhQyVHCJz8YaydHzTqlLZO8R6fMY9JZ9V55f_-T2wSbpMru1Y2JSXyNVE0rIZCNr1lnzWi22qtzJ4MmZwqjEU/s400/ThisIsNotMyBoyfriendsComputer.jpg" width="400" /></a></div>
<br />
I want to share a few interesting conversations with or about women in technology industry: </div>
<br />
<div class="MsoNormal">
A young white American male, on attending <a href="http://ghc.anitaborg.org/2016-attend/" target="_blank"><i>Grace Hopper Celebration</i></a> - a conference by and for women in computing</div>
<blockquote class="tr_bq">
- It felt really weird to be part of the small minority of men there. I usually feel like I belong when I go to technology events, but this was different. </blockquote>
<br />
<hr />
<br />
<div class="MsoNormal">
A different young white American male, works in a heavily male-dominated office</div>
<blockquote class="tr_bq">
- So, as a member of the majority, what can I do to welcome more women to participate in tech?</blockquote>
<div class="MsoNormal">
Another young white American male, same workplace</div>
<blockquote class="tr_bq">
- But we welcome women! We are a total meritocracy. Women just do not apply.</blockquote>
<br />
<hr />
<br />
<div class="MsoNormal">
Mid-career software professional, female, working in the public sector</div>
<blockquote class="tr_bq">
- Yesterday, I suggested researching a way to automatically add new users to "AR" group. I told it three times. It was ignored and dismissed. By the end of the meeting, Garry said exact same thing. Adolfo carefully recorded it in his plan of action.</blockquote>
<div class="MsoNormal">
Experienced white male, in response to the woman’s comment above</div>
<blockquote class="tr_bq">
- Sad that it upset you so much. How much easier would be your work if you just shrug and ignore, even better, do not notice these little injustices. The credit, that little bit of authorship honor, was stolen from you. The whole incident was a waste of time and emotions.</blockquote>
<br />
<hr />
<br />
<div class="MsoNormal">
Another professional woman</div>
<blockquote class="tr_bq">
- I get a flood of emotion when I realize that consistently in our staff meetings one of my male coworkers echoes my comments or objections loudly for the whole group, either in agreement or augmenting them with his own thoughts in legitimate discussion. This is a first in my career that I feel consistently heard, even with the many female coworkers I've had. <b><i>And he is raising a daughter.</i></b></blockquote>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKp7e1_U5i619v2YFNda72nXJ5BhwCjB5rIHz1uQwnDH8DNjUeMSKIZOuP_zy5rkm0YLrTCS0wLIqjSZwdAryqUnJUwwRyKTT5capz4iZMq6jWdb0vhP6PefIcRSmPYi8SEg__uhKs9_mb/s1600/girls.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKp7e1_U5i619v2YFNda72nXJ5BhwCjB5rIHz1uQwnDH8DNjUeMSKIZOuP_zy5rkm0YLrTCS0wLIqjSZwdAryqUnJUwwRyKTT5capz4iZMq6jWdb0vhP6PefIcRSmPYi8SEg__uhKs9_mb/s400/girls.jpg" width="400" /></a></div>
<br />
<br />
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com2tag:blogger.com,1999:blog-7086785636466343363.post-42761962264538061242016-10-29T19:23:00.003-05:002016-10-31T14:54:40.414-05:00Brilliant hare? <div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiROXijRlj7j3-_NzOcGzjgjkNg9vGVQohXIs9Fjf0Ud5bkqMY7PCTp7vVTipKJzMi-91vi-ue_Op_b-eE0BFTyx9ebu3pgY1KPztVI_3bDR8SXKdeAn9AqUeZgse0V1ZTzzs_lvCS9Rt4e/s1600/racing_large_cars.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiROXijRlj7j3-_NzOcGzjgjkNg9vGVQohXIs9Fjf0Ud5bkqMY7PCTp7vVTipKJzMi-91vi-ue_Op_b-eE0BFTyx9ebu3pgY1KPztVI_3bDR8SXKdeAn9AqUeZgse0V1ZTzzs_lvCS9Rt4e/s640/racing_large_cars.jpg" width="426" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<h4 style="text-align: right;">
<span style="font-family: "georgia" , "times new roman" , serif;"><span style="background-color: white; color: #333333;">We called him Tortoise because he taught us.</span> </span><span style="background-color: white; color: #333333;"><span style="font-family: "georgia" , "times new roman" , serif;">- Lewis Carroll</span></span></h4>
<blockquote class="tr_bq" style="clear: both; text-align: center;">
<br /></blockquote>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<o:p><br /></o:p></div>
<div class="MsoNormal">
In a conversation about work, a colleague mentioned that a person who was perceived as absolutely brilliant by everybody who knew him. People
believed he was brilliant, because he was always coming up with answers for
every complicated technical problem or question very quickly. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Being quick is important for success. ‘Quickly’ is one of the
more popular words in LinkedIn recommendations. <a href="http://www.theatlantic.com/technology/archive/2015/06/the-rise-of-speed-listening/396740/" target="_blank">Speed-reading, speed-listening</a>,
and occasionally even fast typing, are considered good and important skills
for technology workers. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Yet, quick can be an enemy of good. Quickly pushing out code
typically leads to bugs, technical debt, and poor architecture. Quick decisions
often turn out to be poor – or maybe not, but only if they happened to be lucky, rather than well thought through. <a href="http://softwareandotherthings.blogspot.com/2016/02/99-little-bugs-in-code.html" target="_blank">The engineer everyone’s raving about for quickly fixing bugs</a>, is quietly introducing dozens of new ones. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<a href="https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555/" target="_blank">“Thinking, Fast and Slow” by Daniel Kahneman</a> talks about the
different ways people are wired to think, one by applying simple rules and
pre-existing biases, another for consciously considering all available
information. The ‘quick thinking’ leads to stereotyping, emotional, and subconscious
choices. The slow option is the opposite – calculating, conscious and
effortful. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<br />
<div class="MsoNormal">
It may be time to rethink what it takes to be brilliant. Slowly. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLpXE9xAoc190KWbTj_XxMi-MFhkLinkC6Fm4B08LFxRXezOy1NPGAqm6S-GZWpoDYrrGiT1tgyEzccAU4knqhlgANvTAdE1pDQKmexB5d8AHThGHpiN4j1WoYx5qQJfRmMWr1ioFBC6Lz/s1600/moscow_car_wreck.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLpXE9xAoc190KWbTj_XxMi-MFhkLinkC6Fm4B08LFxRXezOy1NPGAqm6S-GZWpoDYrrGiT1tgyEzccAU4knqhlgANvTAdE1pDQKmexB5d8AHThGHpiN4j1WoYx5qQJfRmMWr1ioFBC6Lz/s400/moscow_car_wreck.jpg" width="400" /></a></div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com1tag:blogger.com,1999:blog-7086785636466343363.post-1017492551520920662016-08-27T21:12:00.001-05:002016-10-10T13:26:38.119-05:00Work hard, aim high, fall, and keep going<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeyCfrhGb1mte7e7V19l21MW2P22G1-QKdoEQLIlVAbjXOfVNRVTTLxFMCSg2kJG5Sg01QMZVaHUMoxT20NjNgxuvpxgoTaF_xxU4fkNFuHhi_ARtdMzlDRqlZ2qPTqW3i9JGMrGPqSl9D/s1600/try-harder-on-ice.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeyCfrhGb1mte7e7V19l21MW2P22G1-QKdoEQLIlVAbjXOfVNRVTTLxFMCSg2kJG5Sg01QMZVaHUMoxT20NjNgxuvpxgoTaF_xxU4fkNFuHhi_ARtdMzlDRqlZ2qPTqW3i9JGMrGPqSl9D/s1600/try-harder-on-ice.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
I was told that this young woman in a sparkly dress is a top-level athlete at a local ice skating rink. She came out on the ice with powerful confidence of someone who’s done that a hundred times. Indeed, she was very good - graceful glides, balanced turns, fast spins. Then she jumped. And fell. Got up and kept skating, and then jumped again. And fell again. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Those were complicated, high above the ice, many-turns jumps, and she did manage to land nicely a few of them. Still, she fell four times in a two-minute skating routine, all the way down on the ice. And each time she got up, picked up the beat in the music, and continued skating the program. More than that, she continued to attempt those high complicated jumps over and over again, never mind the falls. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
The crowd was watching from the bleachers in awe. Down on the ice, this young woman was living through these, most likely unremarkable, minutes of her life – <b><i>work hard, aim high, fall, and keep going </i></b>at it. Throughout the evening, the skater kept attempting more jumps, sometimes landed nicely, but quite often continued to fall. She was the best, and that was exactly how she got to be the best, by pushing through the failure, the pain, the embarrassment, no matter the falls, jump after jump. <o:p></o:p></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpJijEkcHuZhAEsd8OdXHosQ6cbt57-SOZP4hRZGUNxRlaQdPt57hTT5JOh4zq5f6Mkq98FrkvdOhoo7HgTs2G9ecBERGx5lApXQDHmsmcWrvTFK9iuZgfTz_PyRwdrsdeUatpxjPZ9Mjp/s1600/springs-resilience.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="302" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpJijEkcHuZhAEsd8OdXHosQ6cbt57-SOZP4hRZGUNxRlaQdPt57hTT5JOh4zq5f6Mkq98FrkvdOhoo7HgTs2G9ecBERGx5lApXQDHmsmcWrvTFK9iuZgfTz_PyRwdrsdeUatpxjPZ9Mjp/s400/springs-resilience.jpg" width="400" /></a></div>
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-13639063712627207352016-06-29T12:29:00.004-05:002016-06-29T16:15:09.579-05:00Legacy code cycle<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiePacYHLxpIK7KUNz_g_55l1OCU626LQxcG0GnFtrP9iAbI3z5twER2ePdXeAY4VYUkBFXV9js40WZJvmKPcSiMMxHrDxTll9yDiqtbHoO2oofRc-4XM-jlX4VU4fEMJ3SUcOk09UHRFBh/s1600/hamster-wheel.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiePacYHLxpIK7KUNz_g_55l1OCU626LQxcG0GnFtrP9iAbI3z5twER2ePdXeAY4VYUkBFXV9js40WZJvmKPcSiMMxHrDxTll9yDiqtbHoO2oofRc-4XM-jlX4VU4fEMJ3SUcOk09UHRFBh/s400/hamster-wheel.jpg" width="400" /></a></div>
<br />
<blockquote class="tr_bq">
<h3 style="text-align: right;">
<span style="font-weight: normal;">“Remember, code is your house, <br />
and you have to live in it.” <br />
― Michael C. Feathers<br />
"Working Effectively with Legacy Code"</span></h3>
</blockquote>
</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Every project goes through stages. First, there is excitement of design, green-field development, seeing things work. Then there are bug fixes, additional features that may or may not fit the originally designed architecture, little tweaks and changes to accommodate the cases not covered in initial development. And then there is support – making changes based on the usage patterns, keeping up with changing environment, fixing the harder-to-find bugs. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Successful projects go through these stages in a spiral: as time goes on, large sections will get re-written to update architecture, move to a new technology stack, fix the underlying issues of the old code base. And then more bugs will be written, tweaks and updates will be needed and will tarnish the shiny new design, and environment will continue to change. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
No matter how many times we’ve been there, for most large successful projects, a large portion of the lifecycle is when the code base is full of slow-moving, bug-prone legacy code that is hard to work on. Eventually, an investment will be made to rewrite or refactor the worst pieces, yet a short while later the development organization finds itself facing the same problems again. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
At the same time, developers are being continuously schooled on writing better code, doing TDD, working with legacy code, but all this knowledge turns out to be very hard to put into daily practice.<br />
<br />
<h3>
<span style="font-weight: normal;"><i>Legacy code keeps happening, despite the best intentions.</i></span></h3>
</div>
<div class="MsoNormal">
<o:p></o:p><br />
<i><br />
</i> <br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPn8y0Zqv9iTDmu5Qb-FdyajvOud9iTPL9pkqRnlA3i5KWXw-i5aoyjY7vyD4s7eVmV6Rjpd8ASoVpqTkd_BNd7QNawZpYt54BnxCYJaPQXKgLUXEqfLaOOHefMOeIvKH-D_Zn5NRPwdzP/s1600/FromLegacyToBetterCode.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPn8y0Zqv9iTDmu5Qb-FdyajvOud9iTPL9pkqRnlA3i5KWXw-i5aoyjY7vyD4s7eVmV6Rjpd8ASoVpqTkd_BNd7QNawZpYt54BnxCYJaPQXKgLUXEqfLaOOHefMOeIvKH-D_Zn5NRPwdzP/s320/FromLegacyToBetterCode.png" width="320" /></a></div>
<i><br />
</i></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com3tag:blogger.com,1999:blog-7086785636466343363.post-65911316998085669802016-06-16T15:57:00.000-05:002016-06-16T15:57:33.523-05:00Are we ready for code review?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJcz2HihbQmm_Q0z6wGhvMYwnQgm-mmwqT3aBThV8_lgvYpF_CLwF1lq7NltPZ0om1M-hnT7zxbsq0Iu8TtfkdtDwF2IK5zoPdXCC6WJdmEpJ2NHANzIBMqnb7bYRnRnJbQrnQECBXF7gq/s1600/EffectiveCodeReview-pantsRequired.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJcz2HihbQmm_Q0z6wGhvMYwnQgm-mmwqT3aBThV8_lgvYpF_CLwF1lq7NltPZ0om1M-hnT7zxbsq0Iu8TtfkdtDwF2IK5zoPdXCC6WJdmEpJ2NHANzIBMqnb7bYRnRnJbQrnQECBXF7gq/s400/EffectiveCodeReview-pantsRequired.png" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We have been talking about <a href="http://adnug.org/Home/june-13-2016-effective-code-reviews/" target="_blank">the better ways to do code reviews</a>, and there are plenty. There are great tools to make code sign-off by
someone other than the code author a required part of the process. It is
important to keep code reviews short and casual. Very little code and only a few people should
be involved in each event. Reviews should be done often, as much as a couple of
times a day, and everybody on the team should participate regularly. There are
ways to limit the conversation to the most important topics – logical flow,
proper use of language features, good naming, while leaving formatting, test
coverage, and many other issues to the automated code checkers. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The most interesting conversation, as it typically happens,
took place after the formal presentation. The biggest problem of code reviews,
and all other technical reviews, is that we, the developers, tend to take the
critique as a personal assault. People
brought up multiple instances when they tried to communicate code feedback to a
colleague, and instead their comments were heard as snarky and demeaning. We
discussed learning to be nicer, working on improving <a href="https://en.wikipedia.org/wiki/Emotional_intelligence" target="_blank">Emotional Intelligence</a> and
<a href="https://www.vitalsmarts.com/products-solutions/crucial-conversations/" target="_blank">social skills</a>, making sure to provide comments on good things as well as bad. <o:p></o:p></div>
<br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
However, this is just one side of the problem. There are at
least two parties involved in delivering feedback: a person who endeavors to give the message,
and the person who is to get the information. The person who receives feedback must be open
and involved into how feedback is provided. In order to learn from and benefit
from feedback, we also need better social skills and EQ, as well as trust in
the system and the person who is delivering the feedback. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIM5CZogqWPdHYCQTXnW5w5haGND9nmn-IUWHFxBLHndG_ihtl1e6yQJ8A9Em9embhy-o6ndmFiut037q6r_2Z4fLYkfSiAToysWqsMnKLfeq2Kg2eXyj5xu8K_bGXIS0sYcfzdMIotwx1/s1600/thank-you-for-feedback-book.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIM5CZogqWPdHYCQTXnW5w5haGND9nmn-IUWHFxBLHndG_ihtl1e6yQJ8A9Em9embhy-o6ndmFiut037q6r_2Z4fLYkfSiAToysWqsMnKLfeq2Kg2eXyj5xu8K_bGXIS0sYcfzdMIotwx1/s640/thank-you-for-feedback-book.jpg" width="424" /></a></div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-74775980608157299012016-06-09T15:50:00.000-05:002016-06-10T00:15:23.018-05:00OO is getting old and tired. But is it dead yet? <div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiai32V_mEMFnylonSAe_ETbeaZHkVcIjcv0olikB7OFOEGGOLsRx4b7pn28F5mPlFYx73MSrEjV83KHqw7Ol2FX8WSfaHBH5lvjOOIkeJkp2yZprdukXjlDZomUCdjU-1umROOdrn7Dtay/s1600/IsOODead-ResponseToPragdave.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiai32V_mEMFnylonSAe_ETbeaZHkVcIjcv0olikB7OFOEGGOLsRx4b7pn28F5mPlFYx73MSrEjV83KHqw7Ol2FX8WSfaHBH5lvjOOIkeJkp2yZprdukXjlDZomUCdjU-1umROOdrn7Dtay/s400/IsOODead-ResponseToPragdave.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
Here are a few thoughts inspired by an excellent presentation with a provocative title <a href="http://www.meetup.com/javamug/events/231053287/" target="_blank">“Object-Orientation is Dead, too”</a> by <a href="https://pragdave.me/" target="_blank">Dave Thomas</a> aka <a href="https://twitter.com/pragdave" target="_blank">@pragdave</a><a href="http://www.meetup.com/javamug/events/231053287/" target="_blank">.</a><br />
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
OO has been taken to mean classes, inheritance and polymorphism,
as implemented in a variety of programming languages. As we typically build
code, the proper class design is to commingle state and behavior. Inheritance
provides a simple way to vary some but not all aspects of behavior on connected
objects. And polymorphism provides a way to package different behaviors into
look-alike syntax.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Together, these features make for an incredibly flexible system,
with many different ways to design abstractions, express dependencies, and store
state in many objects across the codebase. Other words for flexible are ‘complex’
and ‘complicated’. The notion that having all this flexibility is good and
powerful and smart encourages mixing a variety of abstractions and
implementations, and long and wide dependency trees. As systems and
corresponding codebases grow over time, accumulating ideas and approaches from
many people, they grow more fragile, more tightly-wound. Code also becomes more
dependent on the past history, rather than the latest, and therefore best,
understanding. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We know all that because OO had had a great run in the last
25+ years. Java, in particular, has been one of the most popular programming languages
since it came out in mid-90s, both by the amount of code written and number of
people writing in it. .Net platform is heavily OO and is very popular as well. C++,
while not exactly a strictly OO programming tool, is frequently used for
OO-style development. Lots of complicated projects have been attempted, and
plenty completed, using the OO paradigm. Many people joined the ranks of OO
developers, people with varying amounts of education, imagination and
cleverness. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In the last quarter century OO paradigm has been applied to
many complicated development projects, at times by less-than-stellar developers,
and often by diverse groups working independently and inconsistently. OOP came out somewhat scathed,
bruised by the many broken abstractions, blemished by millions of lines of legacy
code, but by and large OO has delivered on its promise to provide a way to make large and complex systems possible.</div>
<div class="MsoNormal">
<br /></div>
<h4>
<i>So, is OO dead yet? Or, rather, are we ready to move on to
something newer and better?</i></h4>
<div>
<i><br /></i></div>
<div class="MsoNormal">
It’s been many decades since OO first showed up, handily won
over then-popular procedural programming style, and far eclipsed the popularity
of the functional approach. We are now older, wiser, and have more experience.
Is OO still the silver bullet it has once been? And what are our options?</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Functional languages are powerful, deeply loved by their
communities, and offer a paradigm that can rival OO tools in solving complex
problems. Yet, the functional approach has not enjoyed nearly as wide an
adoption among broader development community. It also did not have such a testing 25+ years, as software projects grew larger, more complex, and continuously involved larger numbers of less skilled people than ever before.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The functional paradigm is worth exploring again, with the experience we did not have back when OOP originally came along and took over the software industry. But the winning paradigm for the next quarter century is far from certain. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDUfS6FLXFZwUkiTjj6O9WmF-_nEP9Elp28AGuyBHp0WWXM6LZAbp01MrgEaBT0wOQiZUjR_m_JB4thjNwos6Lq_2abYa6Tmdm4VWFciWOcMi80hJa5_KJmtLHSWmcqVDQGgvunS5HoLZH/s1600/IsOODead-ResponseToPragdave-silverBullet.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDUfS6FLXFZwUkiTjj6O9WmF-_nEP9Elp28AGuyBHp0WWXM6LZAbp01MrgEaBT0wOQiZUjR_m_JB4thjNwos6Lq_2abYa6Tmdm4VWFciWOcMi80hJa5_KJmtLHSWmcqVDQGgvunS5HoLZH/s400/IsOODead-ResponseToPragdave-silverBullet.png" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-47107563803386694922016-05-06T15:57:00.003-05:002016-05-07T14:26:33.528-05:00Solving for Passion<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1UcCy3ngptvUJnhlcQ-hmgLesRnWZJXCU1P80jioomNFMzifAHPQ7NYAacERN1Wl0OaiQl0r5V02FoKYYu91khD_54MS15p450UKPAK9FPMMMLdZKycCaWSZkVbXSNE3Av142FejEO3sE/s1600/bright-bike.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1UcCy3ngptvUJnhlcQ-hmgLesRnWZJXCU1P80jioomNFMzifAHPQ7NYAacERN1Wl0OaiQl0r5V02FoKYYu91khD_54MS15p450UKPAK9FPMMMLdZKycCaWSZkVbXSNE3Av142FejEO3sE/s400/bright-bike.jpg" width="400" /></a></div>
<br />
For the last few years, I have had the pleasure, and the privilege, to participate in graduating students’ project reviews at a major university. Students in their final semesters of earning a Computer Science or Computer Engineering degree are asked to come up with and implement a project of their own choosing, within the guidelines set forth by the professor for the course. Students typically identify a user or a client for their work – a university department or research lab, consumers, charitable organizations.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A few dozen projects I have reviewed so far have mostly been spectacular. Students put their heart and soul, and considerable skills and passion for the technology, into this assignment. However, there are interesting differences in the presented work. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Some cohorts of students appear to have lofty, large-scale goals. They are interested in solving big important problems related to hunger, or low productivity, or deadly deceases for large populations using tiniest of tools. The teams pull research from international conferences and large NGOs, make highly speculative assumptions about complicated unknowns, and pull together technologies that are both rare and not really designed for these purposes. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
For these projects, results are typically modest, presentations are ambitious on vision and poor on structure, and risk of running into crippling unknowns is high. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Other groups appear to be much better prepared. The projects capitalize on the cutting-edge technologies, tests are neatly recorded on video, and presentation slides showcase the scientific background and beautiful technical documentation. However, these projects aim a bit lower: gadgets that offer a small improvement on the existing products. Polish replaces passion. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
When the focus is on delivering a good-looking presentation, creativity gets lost, or at least greatly diminished. This batch of working, well-documented projects lacks excitement, grand vision, reach into the unknown.<o:p></o:p></div>
<br />
<div class="MsoNormal">
College is the time to dream, to stretch for the moon, to grow one’s ambitions. Most people go on to have a long and very practical career, where delivering a small improvement is valued higher than big ambitious undertakings. We will all be better off if we had more passion and creativity to go around. <o:p></o:p><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5TMC41vRryP5He6q5M7qlUvIJaMZ5ghQQ89wNdgJ-CeAxDHoDz3mvWDUmR-sl_t9Ds4u0j9BpKzf0yC7UDg1xT5TeUZlj8gi-i_mP8w_uIs_alLNM8fzHU7XGExdHbV6aJN7C-Ekttgsf/s1600/blah-blah-meh.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5TMC41vRryP5He6q5M7qlUvIJaMZ5ghQQ89wNdgJ-CeAxDHoDz3mvWDUmR-sl_t9Ds4u0j9BpKzf0yC7UDg1xT5TeUZlj8gi-i_mP8w_uIs_alLNM8fzHU7XGExdHbV6aJN7C-Ekttgsf/s400/blah-blah-meh.png" width="400" /></a></div>
<br /></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-7620445305287095072016-04-21T15:11:00.001-05:002016-04-21T15:11:43.731-05:00Beyond the 'happy path'<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX_dqCr78DRKDlKlIgysOvfaujCXTM8tbRT8qoIevW2ETiXTtBGn5P0sGzphiIPf2wK68DsBsGnSAZK4lqpwpqMbr5i-sXcfMvtFNg0YY-XFZWfaXfJobYBO7WrHKK1HWajjvkdhuhfgaV/s1600/roller-coaster-red.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX_dqCr78DRKDlKlIgysOvfaujCXTM8tbRT8qoIevW2ETiXTtBGn5P0sGzphiIPf2wK68DsBsGnSAZK4lqpwpqMbr5i-sXcfMvtFNg0YY-XFZWfaXfJobYBO7WrHKK1HWajjvkdhuhfgaV/s400/roller-coaster-red.jpg" width="400" /></a></div>
<br />
<blockquote align="right" class="tr_bq">
In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected<br />
<br />
<a align="right" href="https://en.wikipedia.org/wiki/Happy_path" target="_blank">- Wikipedia</a></blockquote>
<br />
Software is possible because we have clear, well-defined expectations in a lot of common situations. Given a problem and a particular state of the world, software can reason through known information, and perform according to the expectations.<br />
<br />
People who invent software are enterprising, excitable, focused on delivering a working solution for a problem. Which mostly translates into building software that is great about performing the ‘can do’ portion of the expectations. It is the so-called happy path, where the software works as desired and designed, in the perfect world for the well-behaved user who happens to think in perfect lock-step with the inventor of the software.<br />
<br />
However, the world is hardly ever perfect. People and users think differently. Not all users are both well-behaved, and can or will follow the detailed vision of the software designer.<br />
<br />
Consider a bank application that allows read access to one’s account balance. It is important that it <b>does NOT</b><br />
<div>
<br />
<ul>
<li>allow read access to other people’s account balance.</li>
<li>allow write access to any account balance.</li>
<li>allow any user behavior to affect other user’s experience and access.</li>
</ul>
<div>
<br /></div>
<div>
These kinds of expectations are less likely to be included in the <b>specification</b>, because we like to think about software in terms of what it can do, and not what it doesn’t do. These expectations are less likely to be designed into the software <b>architecture</b>, because we like to think of achieving our goals must more, than we like to be concerned about preventing bad things from happening. Finally, these expectations are less likely to be <b>tested</b>, because it is both harder and does not demonstrate a job-well-done even if successful. </div>
<div>
<br /></div>
<div>
Better handling the non-happy paths requires a more systematic approach to specification building and testing, and range verification.<br />
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihqdYoxmxgdwQdlMf5NWObOrDN3-g2t_9Z6Zf7RhZzthUl54AlST62ZEycrHAqU85B4Ggz-nm0_igLUqHZ3awo6AfwBEYkY6k6PshqJW4_6JMiqhsU9RT7eMkRaFFtWwVORtTXEWN8lOCW/s1600/roller_coaster_broken.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihqdYoxmxgdwQdlMf5NWObOrDN3-g2t_9Z6Zf7RhZzthUl54AlST62ZEycrHAqU85B4Ggz-nm0_igLUqHZ3awo6AfwBEYkY6k6PshqJW4_6JMiqhsU9RT7eMkRaFFtWwVORtTXEWN8lOCW/s400/roller_coaster_broken.jpg" width="400" /></a></div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
</div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-50759823162817741012016-04-12T11:37:00.001-05:002016-04-12T11:37:30.331-05:00Leading by good looks<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglfzsxEECGNDMT3E0tab-NrXe61cWb8Qj2SE2MRKJyY5wMm4micPQ5l-FOVlc6CQ5dcJceuvD8GsEoCxFZsDi2G0FJfo-kjHbmijJpJICCTSLQVvIfyDnK9i6Al-TYp-lfcCoY4THGaI85/s1600/chess-leadership.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="177" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglfzsxEECGNDMT3E0tab-NrXe61cWb8Qj2SE2MRKJyY5wMm4micPQ5l-FOVlc6CQ5dcJceuvD8GsEoCxFZsDi2G0FJfo-kjHbmijJpJICCTSLQVvIfyDnK9i6Al-TYp-lfcCoY4THGaI85/s400/chess-leadership.jpg" width="400" /></a></div>
<br />
<br />
<blockquote class="tr_bq">
“<i><b>… you don't get trusted positions just because of your ability. You also have to attract the notice of superior[s…]. You have to be liked. You have to fit in with the system. You have to look like what the officers above you think that [leaders] should look like. You have to think in ways that they are comfortable with.</b></i></blockquote>
<blockquote class="tr_bq">
<i><b>The result was that you ended up with a command structure that was top-heavy with guys who looked good […] and talked right and did well enough not to embarrass themselves, while the really good ones quietly did all the serious work and bailed out their superiors and got blamed for errors they had advised against until they eventually got out.</b></i>” <br />
<br />
<b>Ender's Shadow</b>, by Orson Scott Card @1999</blockquote>
<br />
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Likable people that fit within the system do a decent job advancing the system toward success. The kind of success that is easy to imagine, easy to prognosticate, and mostly means being ahead of the competition that does the same thing. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
However, if one wants to shoot for the stars, to change the paradigm, to redefine success – expecting good-looking people who think in ways that are approved by the existing system to lead us there is doomed to fail. Occasionally, success is not so much ‘the same thing, just more and better’, but rather a long shot that could turn out to become something different, powerful and amazing. And then there is a need for a different kind of leadership, the leadership that does not work as hard to look presentable, to say the expected thing, to be liked by the superiors.<br />
<br />
There have always been unlikeable leaders who changed the world in big and small ways. A few went against the system, and others simply disregarded the system and built their own way. The society at large considered most of them failures during a significant portion, if not the entirety, of their journeys. Others have reached the official definition of success, and occasionally even became liked and popular. Still, leading for change is a risky proposition with high potential for failure.</div>
<br />
<div class="MsoNormal">
So when picking a leader, or aspiring to lead, put some thought into what kind of leader you want to follow, or to become. Good looks may not be required. <o:p></o:p><br />
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmsuXUaWBauITuXUAqXJggQlOg4Dh_h-tgU2z1qFvPhSm16DNbAd28Gindlaum2TS_EiZmsIYxgoJrG_fZr84EY5kLutQJavEfGIhHcDMWaO92Lo1py-cY2A8TuhYC-OTW3f-Yrgwre60q/s1600/resized-leadership-pinned.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmsuXUaWBauITuXUAqXJggQlOg4Dh_h-tgU2z1qFvPhSm16DNbAd28Gindlaum2TS_EiZmsIYxgoJrG_fZr84EY5kLutQJavEfGIhHcDMWaO92Lo1py-cY2A8TuhYC-OTW3f-Yrgwre60q/s400/resized-leadership-pinned.jpg" width="400" /></a></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-51755320560416542162016-02-18T16:12:00.001-06:002016-02-18T21:10:49.532-06:00Following Plato Dialogues: conversation about estimates<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh70VaBEuG6tSeX09gPRzPIFoCaivXcpJEx4fbPGeAYjd3i5nxtaLkukY8UdaKYiFrRcpD10Kc14fbrUwQa2sEfDiYNpU_3J3VuUbO7wioqPmL3YmnfMT_hYemXzdVipNYrOwYEtO_5mxUU/s1600/plato_360x450.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh70VaBEuG6tSeX09gPRzPIFoCaivXcpJEx4fbPGeAYjd3i5nxtaLkukY8UdaKYiFrRcpD10Kc14fbrUwQa2sEfDiYNpU_3J3VuUbO7wioqPmL3YmnfMT_hYemXzdVipNYrOwYEtO_5mxUU/s400/plato_360x450.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><span style="font-size: 7pt; font-stretch: normal; text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">So, why do we need estimates?</span><br />
<span style="text-indent: -0.25in;"><br /></span>
<br />
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Well, as a customer, I want to have estimates. <o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Great! In what ways are estimates useful to you? <o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Say, I order from Amazon, and if my purchase does not arrive on the estimated day, I get to request a refund.<o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Huh, so you are rooting for the sender to fail, and that’s why you need estimates? <o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->I guess so. <o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Any other reason to want estimates or tracking?<o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->Well, if as a customer I was promised a certain delivery, and it is getting really close, but the work is less than half done, I can make a determination that I am not getting that delivery. <o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]-->-<span style="font-size: 7pt; font-stretch: normal;"> </span><!--[endif]-->So, the reason you want estimates is to feel reassured that work is being done? To make you more comfortable with the delivery that you do not trust? <o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<br /></div>
</div>
<h4 style="margin-left: 0.25in;">
<i style="font-size: x-large;">What are good and useful reasons to want estimates? </i></h4>
<br />
<div class="MsoNormal" style="margin-left: .25in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbTJGmDXRsBtyrG1GGehaF9lVWca0QU4o9h5kTXufnDBl2wEQnt_jFPvM2Ht7QcwASKR5f0NZYpN8kdLQ3WL4ysuQiu9TiH_JOTurcNFvzylPlOGRJw9CkLUfjVMUuoyEU2ewtWmHuf6Xj/s1600/Missing-The-Target-480x238.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="196" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbTJGmDXRsBtyrG1GGehaF9lVWca0QU4o9h5kTXufnDBl2wEQnt_jFPvM2Ht7QcwASKR5f0NZYpN8kdLQ3WL4ysuQiu9TiH_JOTurcNFvzylPlOGRJw9CkLUfjVMUuoyEU2ewtWmHuf6Xj/s400/Missing-The-Target-480x238.jpg" width="400" /></a></div>
<h4 style="margin-left: .25in;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbTJGmDXRsBtyrG1GGehaF9lVWca0QU4o9h5kTXufnDBl2wEQnt_jFPvM2Ht7QcwASKR5f0NZYpN8kdLQ3WL4ysuQiu9TiH_JOTurcNFvzylPlOGRJw9CkLUfjVMUuoyEU2ewtWmHuf6Xj/s1600/Missing-The-Target-480x238.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><br />
</a></h4>
<div>
<span style="font-size: large;"><i><br />
</i></span></div>
<div class="MsoNormal" style="margin-left: .25in;">
<o:p></o:p></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-12541844696323769202016-02-14T18:39:00.000-06:002016-02-14T18:39:20.963-06:0099 little bugs in the code... <div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigNeQW5JhiO1dKF_dZePnfqliluCcFDpqJmCNj4bva0dU4ni_gt8ej-3dBzof3cUIu3vzxS38uf09JMB0Cgokczf-IgmAGjvLXpeliJ2mO6Vd368Q9-olpUOgWp_j7UPkoc1FEExCAiizT/s1600/bugChess.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="102" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigNeQW5JhiO1dKF_dZePnfqliluCcFDpqJmCNj4bva0dU4ni_gt8ej-3dBzof3cUIu3vzxS38uf09JMB0Cgokczf-IgmAGjvLXpeliJ2mO6Vd368Q9-olpUOgWp_j7UPkoc1FEExCAiizT/s400/bugChess.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
A lot of developers I work with are very good, and many are
very productive. Surprisingly, those are
not necessarily the same people. Unfortunately, it is not always easy to
tell the difference. <o:p></o:p></div>
<br />
Once upon a time, the management at the company* where I worked decided that there were too many bugs in our code base, and an effort must be made to deal with those bugs. So, the team was asked to come in on a Saturday, and work on resolving bugs. The deal included a significant bonus for the developer who closed the most bugs by the end of the day.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Lo and behold, on Monday the winner was announced: the person who got the bonus apparently fixed 27 recorded bugs. He also introduced many new ones, so that the next couple of weeks ended up being devoted to resolving the problems introduced on that bug-fixing Saturday. The team did not dare to record any more bugs, though, for fear of being called in to work on a Saturday again.<o:p></o:p></div>
<br />
<div class="MsoNormal">
The developer who fixed the 27 bugs on that memorable Saturday was getting praised by the management as the most productive employee, while the rest of the team grudgingly worked to resolve the errors he (and, undoubtedly, other people too) has introduced, while the productivity of new feature development came to a stand-still. Since the new bugs were not being recorded, the situation virtually guaranteed that knowledge will be lost as time went on.<o:p></o:p></div>
<br />
<hr />
* The names have been omitted to protect the innocent and the guilty. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEginiYVzhzXZW0bn2xJXO2XEcJyw6GfR6UHGIOYYu2AeiF5xWl9nJPWPsFqh_VqvAIW0JhDEcGuA7ZERmjOu2pga6-mbp_K1WKvjqPXf02wBQrQ8lsl90nV9UX6VqzDLTlPsCyls1yFDvgz/s1600/codeBugs.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEginiYVzhzXZW0bn2xJXO2XEcJyw6GfR6UHGIOYYu2AeiF5xWl9nJPWPsFqh_VqvAIW0JhDEcGuA7ZERmjOu2pga6-mbp_K1WKvjqPXf02wBQrQ8lsl90nV9UX6VqzDLTlPsCyls1yFDvgz/s400/codeBugs.jpg" width="400" /></a></div>
<br />Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-12158144715047691062015-12-22T15:25:00.005-06:002015-12-22T15:53:37.378-06:00Why Agile<div style="text-align: center;">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/jprusakova/19697403822/in/dateposted-public/" title="P1040994"><img alt="P1040994" height="266" src="https://farm1.staticflickr.com/335/19697403822_38e4ff2b47_b.jpg" width="400" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script></div>
<br />
<div class="MsoNormal">
Agile, and it’s most popular implementation <a href="http://www.scrumguides.org/history.html" target="_blank">Scrum</a>, is <a href="http://www.ambysoft.com/surveys/stateOfITUnion201209.html" target="_blank">becoming standard</a> in software development. Yet, each organization’s <a href="http://www.scrumguides.org/history.html" target="_blank">journey to Agile adoption</a> is different, and is not always smooth. Scrum adoption is often a significant change in how the organization functions, a change that requires people to assume new roles, acquire new competencies, develop new relationships. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So, why Agile? Changing the organization is hard work, risky, and painful. What does Scrum deliver to the organization? <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
There are a lot of <a href="http://webgate.ltd.uk/top-10-reasons-to-use-scrum-instead-of-waterfall/" target="_blank">great ways how Agile and Scrum</a> can make a software development organization more productive and successful. Lets look at some of them. <o:p></o:p></div>
<div class="MsoNormal">
</div>
<ul>
<li style="padding: .2em 1em;">Scrum can help restructure and reduce delivery risk and increase <b>predictability</b>: potentially shippable software in small chunks, delivered frequently. The most important structural element of Scrum methodology requires delivering working software every 2-3-week iteration. The product must be ready to ship or release. Continuous focus on upcoming delivery forces the organization to focus on finishing up work quickly, and allows to deliver often and on-time.<br />
</li>
<li style="padding: .2em 1em;">Scrum helps deliver a <b>better product</b>, by encouraging earlier incremental delivery, and regular and frequent communication with customers and stakeholders during development. Frequent incremental deliveries allow to collect feedback on the incrementally delivered, yet already useful, software. Short iteration cycle allows the team to accommodate desired changes as requests come in during the development cycle.<br />
</li>
<li style="padding: .2em 1em;">Agile and Scrum recognize and encourage better software engineering practices, to improve and maintain higher <b>technical quality</b> of the product. Higher software quality allows for fewer bugs, shorter time and less effort adding new functionality and fixing defects, and makes it easier for new developers to become productive working on the product. Commonly suggested practices are automated builds, frequent or continuous integration, automated developer and acceptance testing, requiring and maintaining code quality using automated code analysis tools and code reviews. <br />
</li>
<li style="padding: .2em 1em;">Scrum helps organizations achieve <b>better ROI</b> by delivering better product earlier, and working incrementally. The customers get a chance to start working with the incrementally delivered product earlier. The organization enjoys an even-paced delivery schedule that builds trust with stakeholders, improves morale, and limits pressure and stress.<br />
</li>
<li style="padding: .2em 1em;">Agile approach to software development is built around the understanding that creating software is an inherently complex and complicated business, with tremendous upside, expensive downside, and high uncertainty. Scrum and other Agile frameworks do a great job to allow for experimentation by limiting the impact of mistakes. In order to succeed in a creative enterprise, errors should be allowed and encouraged, and it helps if the mistakes are cheap and easy to identify and fix. Agile encourages <b>communication and experimentation</b>, makes mistakes cheap and visible, and thus creates perfect condition for hitting the ultimate project jack-pot.</li>
</ul>
<div class="MsoNormal">
Have you considered adopting Agile? What are your reasons for the change?</div>
<br />
<div style="text-align: center;">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/jprusakova/15848975735/in/dateposted-public/" title="P1040285"><img alt="P1040285" height="285" src="https://farm8.staticflickr.com/7532/15848975735_ed0806d6de_b.jpg" width="400" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script></div>
Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-9089826335783648752015-12-01T11:19:00.005-06:002015-12-01T11:19:57.278-06:00Dealing with the technical debt<blockquote class="twitter-tweet" lang="en">
<div dir="ltr" lang="en">
Been chewing on the idea suggested by <a href="https://twitter.com/nycplayer">@nycplayer</a> last night that messy code is not technical debt...it's just the interest.</div>
— Sarah Mei (@sarahmei) <a href="https://twitter.com/sarahmei/status/667407548211789824">November 19, 2015</a></blockquote>
<br />
That's an interesting way to think about technical debt. The amount of interest on a debt is controlled by <a href="http://www.investopedia.com/terms/i/interestrate.asp" target="_blank">the interest rate</a>, and also compounding frequency. Higher rate leads to more interest accumulating over time, and so does higher <a href="http://www.accountingcoach.com/present-value-of-a-single-amount/explanation/2" target="_blank">compounding frequency</a>. Compounding frequency for the technical debt interest rate is determined by amount of work that still needs to be done on the code.<br />
<br />
For any level of technical debt, i.e. code mess, the cost of technical debt could potentially be nothing - if that code never gets touched again. <br />
<br />
However, if the codebase is for a useful, living product, chances are it is continuously going through the transformation. Features are being added and removed, bugs are being worked out or at least mitigated, and structure gets updated. That raises the cost of the technical debt in that codebase tremendously, since the interest is being compounded all the time.<br />
<br />
When starting to work on reducing the technical debt in a large codebase, the starting point makes a difference. Starting with the code that changes frequently is a high risk/high return approach: improving technical quality will make a noticeable difference in the technical debt burden. However, it is risky to introduce changes to the code that is exercised a lot and in ways that change frequently.<br />
<br />
Alternatively, one can choose to start with less-frequently touched portions of the codebase, to build experience and understanding. The technical debt reduction benefits will be less significant, but the code changes will also be less risky.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv4_glTaw4b86UZwpoNbI19wk2aOSNv1OTEEJsG1iaSz09SOMetGH9WSJCDwuC6Ypbu9jXEDQdmyv0u3dm_eZ_HPWv-C6JgaSqYYF2958XPEEqqLeCW8LRIz7sMYrmEM6eqS-FEjpS_yD6/s1600/piggyBank.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv4_glTaw4b86UZwpoNbI19wk2aOSNv1OTEEJsG1iaSz09SOMetGH9WSJCDwuC6Ypbu9jXEDQdmyv0u3dm_eZ_HPWv-C6JgaSqYYF2958XPEEqqLeCW8LRIz7sMYrmEM6eqS-FEjpS_yD6/s400/piggyBank.jpg" width="400" /></a></div>
<br />
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-3688843918562970322015-11-01T23:18:00.000-06:002015-11-01T23:18:37.478-06:00Judging Scrum<div style="text-align: center;"><a data-flickr-embed="false" href="https://www.flickr.com/photos/jprusakova/18055985955/in/dateposted-public/" ><img alt="Judging Monkey" height="265" src="https://farm8.staticflickr.com/7683/18055985955_3e851a3454_b.jpg" width="400" /></a></div><br />
Scrum is supposed to be simple. <a href="http://www.scrum.org/">Scrum.org</a> by Scrum creators Jeff Sutherland and Ken Ken Schwaber attempts to define Scrum less than 60 words:<br />
<br />
<blockquote>“Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically. <br />
Scrum itself is a simple framework for effective team collaboration on complex software projects. ”</blockquote><br />
How simple is Scrum, really?<br />
<br />
Scrum, as a management framework, is a practical approach to solving <a href="http://www.businessdictionary.com/definition/agency-problem.html">the Agency problem</a>. Agency problems are pervasive in modern economies due to the extensive division of labour and specialization.[<a href="http://thred.devecon.org/papers/2014/2014-001_Ghatak_Solving_Agency_Problems.pdf">1</a>]<br />
<br />
The problem of agency was first laid out in 1970s[<a href="http://www.pitt.edu/~mitnick/agencytheory/agencytheoryoriginrev11806r.htm">2</a>], noticing the essential imperfection of agency relationships: people (agents) hired to tend to interests of others (principals) actually behave in their own best interests. Economic and institutional approaches to principal-agency problem look at incentive and punishment schemes and various management issues that arise when trying to bring agents’ behavior closer to what the principals would prefer.<br />
<br />
Organizations that engage in software development and IT projects almost always involve a group of people concerned with the final product (principals), and a different group of people (agents) tasked with creating that product. The problem of agency is fairly easy to see in this setting: the interests of the business are not identical to interests of the creators of the product. There are different ideas about what the principals group wants and expects the creators to do, but all agree that interests and behavior of the agents group are never perfectly aligned with principals’ group desires. <br />
<br />
Scrum is one of many systems designed to address the agency problem in the commercial software development and IT space. History and current state of management science and business practices show that the problem of agency continues to lack a perfect solution. Among many systems designed to align behavior of principals and agents in a given business situation, most only achieve a partial solution, and some are unreasonably costly. Like other systems, Scrum may be helpful in achieving a better alignment between principals and agents. Scrum can also turn out to be costly, depending on implementation.<br />
<br />
Scrum targets to improve communication between the two groups, with the idea that better communication will allow for greater transparency and trust. Scrum provides fairly detailed rules for communication structure for the two groups, and instructions for both the principals and the agents how to set and sustain this structure. This generally works, although trust is not a guarantee. However, communication is costly, and is subject to diminishing returns, i.e. more is not always better.<br />
<br />
In addition to the prescribed communication structure, Scrum dictates limited autonomy and accountability for the agents group, and institutes measures to maintain its own framework. These changes are also costly, and run contrary to common organizational structures, thus making them complex to implement. Even worse, the benefits, although sometimes great, may not be easy to quantify, and are very hard to measure.<br />
<br />
While the rules of Scrum appear to be simplistic, the overall system is <b>quite complex</b>, with ambitious goals and significant overhead. Scrum affects operation of both principals and agents, steering emotions on both sides. It effectively introduces a brand-new principal-agent contract, with differently defined roles and responsibilities, and new assumptions about each groups’ motivation.<br />
<br />
Overall, Scrum is an imperfect approach to a very hard problem – one of many imperfect approaches. There is no known solution as of yet, and it is quite possible that such a solution does not exist at all. When considering Scrum against other less-than-perfect attempts to align behavior between principals and agents, it appears that Scrum does <a href="https://www.scrumalliance.org/success-stories">a pretty good job</a> delivering on its goals. Yet, it is far from simple. <br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGlHsyGAvWSI356AigGwzSKsitszyLzTIPXhFJeMMqfxSo-NcbyNIwImTlMqlK_KAHWbq8Tu5HvuAHQT2SO-aqdfJguuUykG8cp2RFXlAgPvXo_7awaWAq_wJ-gq-XW_-ZpYy9l3Gi3n-U/s1600/scrum_large.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGlHsyGAvWSI356AigGwzSKsitszyLzTIPXhFJeMMqfxSo-NcbyNIwImTlMqlK_KAHWbq8Tu5HvuAHQT2SO-aqdfJguuUykG8cp2RFXlAgPvXo_7awaWAq_wJ-gq-XW_-ZpYy9l3Gi3n-U/s400/scrum_large.png" /></a></div>Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0tag:blogger.com,1999:blog-7086785636466343363.post-74090082262775682212015-09-23T23:02:00.001-05:002015-09-23T23:02:10.882-05:00Scrum master woes<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsoXBmQa2G0n1aZmdLzXTTUsCxSsVDgmqiEUmZxVE6X11U4Zb_LJ1NENHh4Iav6YJfXymz_LQ1bKzQF6VI3gHhxkYOGf-l51-B7PnnXaPred-XLG3K5he9LTn4lfN6jLHjr3mak_EvUoco/s1600/hp-a-under-microscope-100339791-orig.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsoXBmQa2G0n1aZmdLzXTTUsCxSsVDgmqiEUmZxVE6X11U4Zb_LJ1NENHh4Iav6YJfXymz_LQ1bKzQF6VI3gHhxkYOGf-l51-B7PnnXaPred-XLG3K5he9LTn4lfN6jLHjr3mak_EvUoco/s400/hp-a-under-microscope-100339791-orig.jpg" width="400" /></a></div><blockquote class="tr_bq">The scrum master was genuinely upset:</blockquote><div class="MsoNormal"><o:p></o:p></div><blockquote><br />
- Scrum is so hard. Engineers do not like it. They feel exposed.<br />
- Well, yes – Scrum calls for transparency, and that is a good thing. Engineers will learn to share.<br />
- But we have to do estimates. And then we have to deliver to those estimates. Then things happen. And engineers hate to do it, and then explain how a task that was estimated at 2 hours took three and a half.</blockquote><div class="MsoNormal"><o:p></o:p></div><div class="MsoNormal"><o:p></o:p></div><div class="MsoNormal"><o:p></o:p></div><div class="MsoNormal"><o:p></o:p></div><br />
<div class="MsoNormal">It is easy to see why engineers do not like this process. Rapid churn of iterations calls for very frequent estimates – and regular inspections of why these estimates turned out to be not quite right. It is painful to be continuously wrong, and even more frustrating to have to defend tiny details of the complex minutiae that is software development.<o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">What can the team, and the Scrum Master, do, to lessen the pain? <o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">The scope of estimates is negotiated between the project manager or product owner, and the product team. Many a project manager would like correct, non-changing estimates provided on the first day of the project. Many a team would be perfectly happy to not estimate at all. Usually, neither gets exactly what she wants, but instead negotiates a compromise with the other side.<o:p></o:p></div><div class="MsoNormal"><br />
</div><h4>The scale of possible compromise solutions</h4><div class="MsoNormal"></div><ul><li><b>The team does not provide any estimates.</b> Project manager, with the help of the Scrum Master, makes educated guesses, based on their experience with the team and the project, when the backlog items will be completed. In this case the team may not share how it is breaking down the work, the progress it is making during the iteration, nor the problems it encounters. Priority of backlog items is established based on their value, and only project managers’ perception of the size and complexity of each item, since the team may not share its evaluation.</li><br>
<li><b>The team provides detailed estimates to project manager at each iteration, and works hard to deliver per estimated completion times.</b> Project manager gets a full report of each working hour of the product team, and gets to control how the work is broken down and accomplished by the team. In this case the team may not be fully forthcoming about how long each tiny item will take, and pads the estimated schedule so that there is enough slack to deliver even if things go wrong. Even if everything goes fine, the team is more likely to deliver on a padded schedule and use the slack time to relax, rather than forge ahead. Even with seriously padded timeline, estimates are often too optimistic, in which case the team will be blamed for incorrect estimates, encouraging even more padding going forward. Detailed estimates take a lot of time and effort, and so does hiding the slack/padded time that the team puts into estimates. The team will be working harder, without a corresponding rise in productivity.</li><br>
<li><b>The team provides coarse-grained relative estimates, by sharing with the project manager how hard each item of work is expected to be. </b>The expected delivery timeline can be deduced, but is not promised, so that the project manager shares in the uncertainty of software development. Still, the project manager can use that information to adjust priorities of various backlog items. The product team does not have to be defensive about not delivering per estimates, because no particular timeline is being promised. The mutual expectation is that most of the estimates will turn out to be wrong, but when the estimates are averaged over multiple backlog items and several iterations, they will provide valuable, actionable information to the team, the project manager, and the rest of the organization.</li><br>
</ul><div class="MsoNormal"><o:p></o:p></div><h4><br />
</h4><h4>What are coarse-grained estimates?</h4><div class="MsoNormal"><br />
It is helpful to classify pieces of work on a scale of Trivial, Small, Large, etc. Fewer options means coarser estimates. Using numbers (prime, Fibonacci, etc.) may encourage defining too fine-grain a division. Using hours or days creates a direct timeline, suggesting that a particular delivery date has been promised. Another option is to use anonymous units of complexity, and those are great if the team can in fact treat them as abstract units (and not convert units into timeline, as it often happens). <o:p></o:p><br />
<br />
Having less-than-perfect estimates, and no timeline, requires and helps build trust between the team and the project manager. The team is held responsible for the average productivity, rather than each particular estimate. The project manager is asked to give up the illusion of full control over the project timeline and trust the team to deliver as best they can.<br />
<br />
Scrum Master is tasked with negotiating the compromise, and holding both sides responsible for their respective contributions.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBz_eZjKzSOSrTbFBverY4yRoqw-c6JRHpxFKimeCGt4hIGf9yzqDgwXY0LDOa3j7st4ZkBZ0g59-NzF3gGjEwVZ88261YXY-q9z24Iprf6aj84TalWcEqCpWhqRHyUpXW11X9ECFuugSv/s1600/Large-VS-Small-Dogs.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBz_eZjKzSOSrTbFBverY4yRoqw-c6JRHpxFKimeCGt4hIGf9yzqDgwXY0LDOa3j7st4ZkBZ0g59-NzF3gGjEwVZ88261YXY-q9z24Iprf6aj84TalWcEqCpWhqRHyUpXW11X9ECFuugSv/s400/Large-VS-Small-Dogs.jpg" width="400" /></a></div><br />
</div>Jane Prusakovahttp://www.blogger.com/profile/18380145396531723557noreply@blogger.com0