tag:blogger.com,1999:blog-21448132106033794212024-03-13T12:13:08.240+11:00Geek DivaBuilding big things in a rainy cityDamana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.comBlogger184125tag:blogger.com,1999:blog-2144813210603379421.post-64543391524552605282016-06-06T11:56:00.002+10:002016-06-06T11:56:53.888+10:00Acknowledge Me<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.amazon.com/Apple-Human-Interface-Guidelines-Desktop/dp/0201177536?ie=UTF8&*Version*=1&*entries*=0"><img alt=" https://www.amazon.com/Apple-Human-Interface-Guidelines-Desktop/dp/0201177536?ie=UTF8&*Version*=1&*entries*=0" border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZ_5MtJ7_FF422Pg6EBz8x63f7k-HA9yecoT_LRPfMWj0K99V8EMCIEO1LMu5_48hyphenhyphenvITcJbRwWAwMITNbanytvIZQ4ltyFHVwYKdlaDbwTrxSvC5HzzPMzfvoOgFz0oPxGmO_IY2sml0/s320/mac.jpg" width="241" /></a></div>
<br />
<br />
Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the change was made, it was set. There was no canceling, accepting or double checking that the user wanted this.<br />
<br />
In the controlled and consistent interface that is the iPhone, iPad and and iWhatever, this worked and even became understandable.<br />
<br />
The problem arose when other platforms and standalone apps outside of the Apple ecosystem started accepting changes without asking me if I was sure about them.<br />
<br />
There is a concept behind any user interaction in software that must be obeyed or these kinds of final decisions without confirmation can hurt rather than streamline the process. It is consistency across the platform.<br />
<br />
Instead of trusting Facebook or other apps to make my changes without acknowledgement which allegedly saves me an extra interaction and click, I make the changes and then open the setting again to ensure it stuck.<br />
<br />
I'm also stuck with the concern around whether I remembered what I had it set to before. If it is a toggle then that's not the end of the world but anything more than two choices and I sit there in despair hoping that there are no large consequences.<br />
<br />
Although Apple has owned user interface designs since 1987 with the <a href="https://www.amazon.com/Apple-Human-Interface-Guidelines-Desktop/dp/0201177536?ie=UTF8&*Version*=1&*entries*=0">Macintosh Human Interface Guidelines</a>, you are not all Apple. You do not control all behaviour in your world.<br />
<br />
If you are going to make a change that sticks then make that so consistent that I will not doubt it or just do the decent thing and <b>ask me for acknowledgement</b>. You aren't saving me a click. You simply haven't earned my undying trust.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-25590577513255032302015-05-07T14:15:00.000+10:002015-05-07T14:15:08.773+10:00Changing Countries Weakened My Mojo but I Just Got It Back<div dir="ltr" style="text-align: left;" trbidi="on">
Changing jobs always involves adjusting to the new environment and finding your feet again.<br />
<br />
Changing countries as well is a career culture shock of epic proportions.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl9X11JMbynoOoMrskYGPDnVZVCtk6XwzfybYKWqiYww7Fj9wxiqEIfAzwp76RKHNxq2Cx6r3a-NfY9e0Vw3pcF_ZyavmkjGOGpxxjj2J_Mi0Oa5UUh4MCbdcTYFCpwyhWQZRpc4NvABw/s1600/mojo.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl9X11JMbynoOoMrskYGPDnVZVCtk6XwzfybYKWqiYww7Fj9wxiqEIfAzwp76RKHNxq2Cx6r3a-NfY9e0Vw3pcF_ZyavmkjGOGpxxjj2J_Mi0Oa5UUh4MCbdcTYFCpwyhWQZRpc4NvABw/s1600/mojo.jpeg" height="276" width="320" /></a></div>
<br />
<br />
I've been doing this work thing I do for a while and feel pretty comfortable with my method and my madness in achieving any goals I am set. The thing is that being in a new work culture combined with a new country has shaken my confidence in what I do and how well I do it.<br />
<br />
A lot of this comes from working with people who have their own very successful ways of doing things that simply aren't my ways. The reality is that there are many ways to achieve the same requirement with each being completely valid.<br />
<br />
My skill set involves becoming adept at functioning inside a new environment very quickly. This is why I'm surprised at how long it has taken me to become comfortable with who I am and what I'm doing in my current job.<br />
<br />
The environment I work in has many rules and is constantly in a highly productive state of cognitive dissonance. It works but it does involve being brutally decisive and being right a lot.<br />
<br />
To me, the only way to be highly decisive and be right a lot is to trust the almost two decades of skills and experience that I have under my belt. Yes, listen to others but do what you know is right for you in that context.<br />
<br />
The two times that I have done something I felt ill at ease with but persisted with anyway, I have come out in a situation that I do not feel went brilliantly.<br />
<br />
It is finally starting to dawn on me that I know how to do this job with my eyes closed and as long as I second guess myself, I will not rock it like I normally do.<br />
<br />
Although changing jobs and countries weakened my mojo, I've finally found a way to get it back.<br />
<br />
She who hesitates is lost. Just go with your gut. </div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-50931880612885056982015-05-06T17:01:00.000+10:002015-05-06T17:01:49.205+10:00How Public Shaming Only Made Me Stronger<div dir="ltr" style="text-align: left;" trbidi="on">
I work at one of those massive companies with a name everyone knows. My Mum is proud to tell everyone I work at a big book store and I'm very happy with the job I moved to a new country to do.<br />
<br />
In the 17th year of my career, I have seen it all. The big companies. The technical power houses that people long to work for. The money factories where I was paid more than small countries to do what I do. Even the start ups that lost me money and some that made me comfortable. The small backwater towns that I worked in while hiding out from the real tech world. Seen. It. All.<br />
<br />
Recently at work, I was advised by my manager to send an email to an internal group of peers. This group represent the entire fleet of people at my company that work in my role. That is not a small number. So, not just my peers but people I want to be like when I grow up.<br />
<br />
I wrote the email and sent it off.<br />
<br />
Yes, I could have worded it better. Although, I did get a review before I sent it. All the good that did.<br />
<br />
Then one guy said "I think you should check with the security group before you ask that" and he meant well.<br />
<br />
Then the assault came. The public shamers who told me what I had done was equivalent to lighting orphans on fire for entertainment and selling tickets.<br />
<br />
Then the private shamers who emailed me with a helpful tone to tell me that I had effed up and needed to consider my actions.<br />
<br />
I did check with that security group and all was ok.<br />
<br />
Yes, I could have worded it better.<br />
<br />
The whole incident made me want to crawl under my desk and never show my face again.<br />
<br />
But for each person who kicked me, ten sent me messages of support. They said things like:<br />
<br />
<ul style="text-align: left;">
<li>"there are people who will make you look bad to make themselves look good";</li>
<li>"at least you didn't take down the entire US website"; and</li>
<li>"I did that once and someone else will do something soon and they will forget you."</li>
</ul>
<div>
I have pretty thick skin. Every mistake I make is a learning experience. I'll be fine.</div>
<div>
<br /></div>
<div>
The thing I dislike about this kind of public shaming is that it makes onlookers afraid to try anything and restricts the amazing people they hire.</div>
<div>
<br /></div>
<div>
Yeah, I may never mail that mailing list again for help. I will have to deal with people saying "Oh, you're that Damana from the mailing list who got her arse kicked" and other interesting comments. It doesn't matter to me.</div>
<div>
<br /></div>
<div>
After a week of feeling terrible about myself, I realised I made a mistake in the way I executed my objective. Next time, I will do better.</div>
<div>
<br /></div>
<div>
What made me much stronger was realising that I don't need to publicly shame someone to feel better about myself. That is a good trait. A better one than pointing and sniggering.</div>
</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-38193149910666623222015-01-14T22:29:00.001+11:002015-01-14T22:33:32.686+11:00The First Is A Lie<div dir="ltr" style="text-align: left;" trbidi="on">
Lately, I've been hyper aware of the first choice in web drop down lists. Yes, yes, I need a hobby.<br />
<br />
When unsubscribing from a bunch of mailing lists, I've found I lazily choose the first option for "Reason" when I'm asked. This goes back to me wanting a one-click subscribe but beyond that, I will also choose the first option.<br />
<br />
If you are thinking about asking a question and not putting yourself out of business then think about what your first choice in a list is. Don't let it be your worst option, even if it is alphabetical.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-82742861332883589892015-01-11T17:27:00.000+11:002015-01-11T17:27:09.001+11:00Spam a Lot<div dir="ltr" style="text-align: left;" trbidi="on">
If I attempt to unsubscribe from a email distribution and it is more difficult than two clicks, I will mark their email as spam. If you're implementing an unsubscribe mechanism for mass mailing then keep this in mind. Systems like gmail and other mail servers will start quarantining or marking all your mail as spam. This means that your valid subscribers may also miss your mail now.<br />
<br />
One thing I've learnt about usability is that if I'm doing it then there are millions doing the same thing. Especially when it comes to exerting too much effort.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-8984341746094040942014-11-17T19:56:00.000+11:002014-11-18T15:53:08.668+11:00Oakton DVS Agile<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT0Dg1CLILqGa0j05JoKyfBh8KadGMJhvbTK8MsTtt-d6cNzZOjq2I89qYYQVwaGdeEIb6S3Gth0XhoZBc30oHbaBjgOKhPOcW7WUU_hUTSPUchFaeKaSX-DpocXpfAflGPTygJ4-hvB8/s1600/DVS+Agile.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT0Dg1CLILqGa0j05JoKyfBh8KadGMJhvbTK8MsTtt-d6cNzZOjq2I89qYYQVwaGdeEIb6S3Gth0XhoZBc30oHbaBjgOKhPOcW7WUU_hUTSPUchFaeKaSX-DpocXpfAflGPTygJ4-hvB8/s1600/DVS+Agile.JPG" height="300" width="400" /></a></div>
<br />
When I complete a project delivery, I like to make sure that I list the agile practices that were used to achieve this goal.<br />
<br />
No matter what people tell you about agile, there is no one way to do it. I have delivered and managed many agile teams over the years and even the same team across multiple projects and I have never once seen exactly the same agile practices set used twice.<br />
<br />
Just as fingerprints are different between individuals, so are agile practice sets for teams. The variables are so vast that no two will be the same, beit the product being built, the team and parts of its sum or the baggage we all carry from job to job.<br />
<br />
This is normal and this is why I keep track of all the combinations as I go along.<br />
<br />
In the case of the Document Verification Service that we built for the Commonwealth Government's Attorney General's Department, the picture above shows the practices and some of the tools we used.<br />
<br />
It is grouped in to development, management and analysis (BA and QA together) practices. Some of course, overlap.<br />
<br />
Always keep track of what worked and what didn't. Try them in your next project but don't force them. Sometimes the best practice on one team will die brutally on another and vice versa.<br />
<br />
Just as agile allows projects to adjust with changing requirements, agile itself changes for its team requirements.<br />
<br />
Rigour over rigidity, always.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-2707813614231884582014-11-06T19:44:00.001+11:002014-11-06T19:44:35.186+11:00Resume + Character is what I want<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjo_V_C0MdzB0KKQHuAOhGmXfpL23LWGTod06nB11XbfonsQEsreCAZPKFcKxCZkbyve1sMg4Fyel5t4VG4DuIQ-1vkkgw0M0QCC4EhmJiVWhzZE-UPrexpbtaSfZSoDlw3l7R8okG9Apw/s1600/checklist.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjo_V_C0MdzB0KKQHuAOhGmXfpL23LWGTod06nB11XbfonsQEsreCAZPKFcKxCZkbyve1sMg4Fyel5t4VG4DuIQ-1vkkgw0M0QCC4EhmJiVWhzZE-UPrexpbtaSfZSoDlw3l7R8okG9Apw/s1600/checklist.jpg" /></a></div>
<br />
<br />
A resume does a good job of describing specific skills. Today I had lunch with a group from my last contract and then an evening of pampering with the women I work with in my current role.<br />
<br />
Reference checks and resumes don't tell me how awesome you are as a person or why your ex-colleagues still love being around you. How do we judge a person's character when all we have is a list of jobs?<br />
<br />
I think it's a combination of what is on paper and what you see in an interview. Let people reveal themselves face to face. Talk to people who know them. Look for character as well as a checklist of skills.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-66004959738020655962014-08-27T22:46:00.000+10:002014-08-27T22:47:49.524+10:00Why Organisational Culture Comes From the Top<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPoF6vpOfPvEXAF9rXikPBjNo35f-mu5qHcr4ipO2uh5ujxrK_TpjUkZWKWAoJJPehG-vmYxQN5ms_X0Vb3RVoFoHpldyzPCwuaxG8HoTNThOebv0Reat4bKXwwwIfSSuqtKmubQ4jeqE/s1600/falling+cards.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPoF6vpOfPvEXAF9rXikPBjNo35f-mu5qHcr4ipO2uh5ujxrK_TpjUkZWKWAoJJPehG-vmYxQN5ms_X0Vb3RVoFoHpldyzPCwuaxG8HoTNThOebv0Reat4bKXwwwIfSSuqtKmubQ4jeqE/s1600/falling+cards.jpg" height="239" width="320" /></a></div>
<br />
<br />
When you are a doer, you want people to let you do your job and to help you improve at it. You need senior people who enable you.<br />
<br />
When you are senior or a lead, you want people to let you do your job and to help people around you. At this point, you know how to improve yourself but you need to be allowed the space to grow and move.<br />
<br />
When you are a team, group or organisational leader, you want people to let you do your job and to enable those around you to do their jobs. You want to aid in individual and organisational growth.<br />
<br />
If one of these points in the hierarchy doesn't want to enable others and instead focuses on themselves with little to no regard towards those around them then organisational culture changes. In my opinion, it changes for the worse.<br />
<br />
Too many places I have worked see leaders who see their career journey and their need to climb a corporate or financial ladder as more important than the people around them. When they finally achieve the power required to drive their own careers, they declare it "every man for themselves!" and start kissing up and kicking down. Or worse, they simply neglect their teams.<br />
<br />
I asked a recent manager in a past job if he cared about his team at all and the dysfunction that was tearing his team apart. He said to me "I don't have time to care." At that point, I reached out to my network and found myself a new job.<br />
<br />
You shouldn't work for a manager or leader or boss who doesn't have time to care about his or her team. Nothing good comes from that.<br />
<br />
If you look above you in an organisation and don't see anyone caring about the people who work for them then leave. If you look around you and can find no allies who will fight for your team over themselves then leave. If you don't want to enable the people you work with or aren't allowed to then leave.<br />
<br />
I once had a manager who told me to stop enabling people because it was getting in the way of them working. He also thought bums on seats was more important than productivity which ultimately drove his subordinates to avoid his desk to take coffee and toilet breaks so he wouldn't see them. He didn't want anyone to be allowed to grow and achieve in their roles. Instead, he wanted them to clock in and clock out and show him the appropriate amount of fear inspired respect. As you can imagine, his team ended up as toxic and broken as he was.<br />
<br />
Organisational growth comes from its leaders. So does organisational rot.<br />
<br />
If you can respect the leaders around you then you will like your job and where you work. If you can't get near them, don't know what they represent or purely dislike their ethos then you need to go somewhere else.<br />
<br />
Organisations can not be healed from the bottom. They are shaped and scented from the top.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-71632741589923818412014-08-26T22:20:00.000+10:002014-08-26T22:20:30.159+10:00I was humble once and I was awesome at it or 5 Rules to Being a Great Team Lead<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4aBOpxn3kdvnK0dKUeslwCH8x0kvP-BvnwbLTwDHFh405XaoILybDPEP5a8cqv3B2xqMJXYiIPLPB4F4FZehCsbDwdQ4o61Ms9F2KzSWc5AYhZ62nTT7Mb_8jnl-nrB7d1BGeMWJ4Vos/s1600/arm.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4aBOpxn3kdvnK0dKUeslwCH8x0kvP-BvnwbLTwDHFh405XaoILybDPEP5a8cqv3B2xqMJXYiIPLPB4F4FZehCsbDwdQ4o61Ms9F2KzSWc5AYhZ62nTT7Mb_8jnl-nrB7d1BGeMWJ4Vos/s1600/arm.jpg" height="320" width="213" /></a></div>
<br />
I often mock humility with my favourite saying "I was humble once and I was awesome at it."<br />
<br />
The truth is that I think humility is a virtue. It is a moral excellence and one that many claim to possess but then fail miserably at.<br />
<br />
The reason I bring it up in this context is because you can not enable and serve a team unless you possess the ability to put yourself last and not aspire to take the credit.<br />
<br />
In the last few years, I have worked with egos that would sink the Titanic. Most have been brilliant individuals that for some reason craved the acknowledgement of their brilliance to sustain them.<br />
<br />
There is one thing that I do well and it is building teams. That doesn't mean I am awesome at hiring geniuses. It doesn't mean I am great at finding combinations of people that work together. That doesn't mean my teams exist because of me. The one thing I do well is serve my teams. I exist to build a safe and sustaining environment that allows people to do their jobs.<br />
<br />
People want to do good work. They want the 8 hours they spend every day to mean something. Most people don't want to run the world. In fact, they want that kind of rubbish to be kept out of their way so they can contribute to the best of their abilities.<br />
<br />
I have five rules that I believe make a great team lead:<br />
<br />
<ol style="text-align: left;">
<li>Lead from behind - enable your team to do what they do best. Don't pull them along by a collar;</li>
<li>Share the fame and share the blame - don't single anyone out as a hero or a villain. Teams produce great results, not individuals;</li>
<li>Celebrate all the wins, no matter the size - don't wait for external validation to celebrate your team. Make the little moments big moments and the big moments, amazing;</li>
<li>Lead the charge and die trying - always be part of delivery and contribute to success. No one will follow you if they don't think you truly understand what it is like to be them; and </li>
<li>Have fun - life is too short to be serious all the time. There is a time for seriousness and that is usually with your clients. With your team, you should be a person who laughs or cries or falls flat on your face. Being real will allow people to be themselves and when they are themselves, they will be great.</li>
</ol>
<div>
Humility involves succeeding and failing. Both are valid. Failing is ok as long as you learn from it. Success is ok as long is it doesn't go to your head.</div>
</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-81587266600876144492014-06-23T22:59:00.000+10:002014-06-23T22:59:56.611+10:00User Story with Technical Use Case Template<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal" style="background-color: white; text-align: left;">
<div style="text-align: left;">
<span style="font-family: arial, sans-serif;">Every single time I join a new agile team, I am asked the same thing - How do you write a user story?</span><br />
<span style="font-family: arial, sans-serif;"><br /></span>
<span style="font-family: arial, sans-serif;">There are many ways to achieve this. Here is mine template of choice. It is a User Story with Technical Use Case template. The hardest part everyone has when writing a story is defining Business Value. If your users wouldn't say it then it isn't business value. Keep that in mind.</span><br />
<span style="font-family: arial, sans-serif;"><br /></span>
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;">User Story: @id</span></h3>
<span style="font-family: arial, sans-serif;"><br /></span>
<div style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>User Story:</b> [One line description of the story. Keep it short as this is how the team will refer to the story. e.g. Eligible User logs in]</span></div>
<span style="font-family: arial, sans-serif;"><br /></span>
<span style="font-family: arial, sans-serif;"><b>As a/an</b> [persona/user/role/consuming-system e.g. Eligible User]</span><br />
<span style="font-family: arial, sans-serif;"><b>I want to</b> [do a function of the system e.g. Log in]</span><br />
<span style="font-family: arial, sans-serif;"><b>So that</b> [business value e.g. Access my information]</span><br />
<span style="font-family: arial, sans-serif;"><br /></span>
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>Main Flow</b></span></h3>
<span style="font-family: arial, sans-serif;"><b><i>Preconditions/Entry Criteria</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an unordered set of conditions that must be met before the first step can begin.</span></li>
<li><span style="font-family: arial, sans-serif;">E.g. The user is on the login page</span></li>
<li><span style="font-family: arial, sans-serif;">E.g. The user has already been added as a valid user with a username and password</span></li>
<li><span style="font-family: arial, sans-serif;">…</span></li>
</ul>
<br />
<span style="font-family: arial, sans-serif;"><br /></span>
<span style="font-family: arial, sans-serif;"><b><i>Steps</i></b></span><br />
<span style="font-family: arial, sans-serif;">1. This is an ordered numbered list of steps that represents the happy path through the workflow.</span><br />
<span style="font-family: arial, sans-serif;">2. E.g. User enteres username and password.</span><br />
<span style="font-family: arial, sans-serif;">3. E.g. User clicks the “Login” button.</span><br />
<span style="font-family: arial, sans-serif;">4. E.g. User is authenticated and authorised and shown the Successfully Logged In page.</span><br />
<span style="font-family: arial, sans-serif;">5. …</span><br />
<span style="font-family: arial, sans-serif;"><br /></span>
<span style="font-family: arial, sans-serif;"><b><i>Post Conditions/Acceptance Criteria/Exit Criteria</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an unordered list of conditions that must be satisfied in order for the flow to be considered completed.</span></li>
<li><span style="font-family: arial, sans-serif;">E.g. User sees the Successfully Logged In page. </span></li>
<li><span style="font-family: arial, sans-serif;">…</span></li>
</ul>
<br />
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>Alternate Flow 1</b></span></h3>
<span style="font-family: arial, sans-serif;"><b><i>Preconditions/Entry Criteria</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an unordered set of conditions that must be met before the next step can begin.</span></li>
<li><span style="font-family: arial, sans-serif;">E.g. User login was unsuccessful</span></li>
<li><span style="font-family: arial, sans-serif;">…</span></li>
</ul>
<br />
<span style="font-family: arial, sans-serif;"><b><i><br /></i></b></span>
<span style="font-family: arial, sans-serif;"><b><i>Steps</i></b></span><br />
<span style="font-family: arial, sans-serif;">4.1 This is an ordered numbered list of steps that represents the happy path through the workflow.</span><br />
<span style="font-family: arial, sans-serif;">4.2 This included all error flow but not exception flow.</span><br />
<span style="font-family: arial, sans-serif;">4.3 E.g. User sees the Login page with an unsuccessful message .</span><br />
<span style="font-family: arial, sans-serif;">4.4 E.g. User is able to retry logging in.</span><br />
<span style="font-family: arial, sans-serif;">4.5 …</span><br />
<span style="font-family: arial, sans-serif;"><br /></span>
<span style="font-family: arial, sans-serif;"><b><i>Post Conditions/Acceptance Criteria/Exit Criteria</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an unordered list of conditions that must be met for the story to be complete.</span></li>
</ul>
<br />
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>Alternate Flow 2</b></span></h3>
<h4 style="text-align: left;">
<div style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b> … </b></span></div>
<div style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b><br /></b></span></div>
</h4>
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>Alternate Flow 3</b></span></h3>
<div style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>… </b></span></div>
<span style="font-family: arial, sans-serif;"><br /></span>
<h3 style="text-align: left;">
<span style="font-family: arial, sans-serif;"><b>Exception Flow</b></span></h3>
<span style="font-family: arial, sans-serif;"><b><i>Preconditions/Entry Criteria</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an unordered set of conditions that must be met before the next step can begin.</span></li>
<li><span style="font-family: arial, sans-serif;">E.g. A system exception has been thrown.</span></li>
<li><span style="font-family: arial, sans-serif;">…</span></li>
</ul>
<br />
<span style="font-family: arial, sans-serif;"><b><i>Steps</i></b></span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: arial, sans-serif;">This is an ordered numbered list of steps that represents what happens every time there is an exception in the flow that can’t be anticipated. </span></li>
<li><span style="font-family: arial, sans-serif;">E.g. User sees the Error page with an filtered error message</span></li>
<li><span style="font-family: arial, sans-serif;">…</span></li>
</ul>
<br />
<span style="font-family: arial, sans-serif;"><b><i>Post Conditions/Acceptance Criteria/Exit Criteria</i></b></span><br />
<br />
<ul style="text-align: left;"></ul>
<br />
<li><span style="font-family: arial, sans-serif;">This is an unordered list of conditions that must be met for the story to be complete.</span></li>
</div>
</div>
</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-6256651311594348352014-05-11T22:21:00.000+10:002014-05-11T22:25:56.050+10:00Top 3 Irrational Fears when Designing Web Sites for Mobiles<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcjuxxVdWrPYHQYT-cBEauGDS7kGie0f14in3-d4J9qHtTkH7U0QN4vciaXhyphenhyphenyV82a4qnDNEdHW8CyKUKIMeqRkkcTfIveZv90kovCQ5p_Aj66ECxavupHx9pFgi7sFq7olEjdSYU6ARk/s1600/liar.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcjuxxVdWrPYHQYT-cBEauGDS7kGie0f14in3-d4J9qHtTkH7U0QN4vciaXhyphenhyphenyV82a4qnDNEdHW8CyKUKIMeqRkkcTfIveZv90kovCQ5p_Aj66ECxavupHx9pFgi7sFq7olEjdSYU6ARk/s1600/liar.jpg" height="254" width="320" /></a></div>
<br />
<br />
Over the last three years there has been an explosion of web development for apps being required to run in browsers on desktops, laptops, mobile and tablets. With the savvy user, moves to improved touch acceptance and further short attention spans, user interface design has changed.<br />
<br />
Prior to the current climate, everyone wanted to direct users to their own native apps that would give a richer experience. It is now accepted that rich native apps are the domain of the user who has already committed to your brand, service or product. They have been using your online or offline business for a while and now want quick and continuous access to you.<br />
<br />
It is not often the case that users are won over to loyalty and consistent use to mobile apps unless there is a gimmick, game or hardware specific reason for the uptake.<br />
<br />
A lot of people are using the browsers on their phones and tablets, in the same way that they use the browser on their laptop or even more retro desktop machine.<br />
<br />
This means that every web developer must be aware that they are designing their apps for users who will browse them on multiple platforms, in multiple browsers and with very little momentary predictability.<br />
<br />
With this in mind, developers are freaking out about what good web site design means. With that panic comes fear of moving from old web design habits based in skeuomorphic principles to newer interactive flat designs.<br />
<br />
When I work with people to build multi-view web applications (usually in ASP.NET MVC), I make an effort to beat out of them their top 3 irrational fears.<br />
<br />
<br class="Apple-interchange-newline" />
<b>Mobile over Everything</b><br />
No matter what you tell yourself or how much you want to believe that people lounge in front of their laptops on the couch at home using your web site, you will have to come to accept that the majority of people will view your site on a mobile device.<br />
<br />
If this isn't in the case right now then it will be absolute within the next year. People use their phones to check the weather instead of walking outside. People use their phones to access social media before they roll over and kiss their partner good morning. People judge your web site by the way it looks in their mobile browser.<br />
<br />
You don't want to fail at this step. Don't be afraid though, this like everything else in our profession is a solved problem.<br />
<br />
<br />
<b>Scrolling over Pages</b><br />
As touch interaction becomes more useable with newer mobile phones, tablets and touch enabled laptops and monitors people are more inclined to click on links on websites. However, this is more usable in higher resolutions and not always so friendly in the phone space where you sometimes feel like you are bashing the screen with your gorilla fist.<br />
<br />
With that in mind, the rule of never scrolling that we were taught at the start of Web 2.0 is no more. Scrolling is what people do without hesitation or irritation on mobile devices. It is an opposable thumb swipe that behaves exactly as they expect without the concerted effort of clicking a link between two other links that might not be the one you meant to click.<br />
<br />
Stick with the rule of scrolling in one direction and you will have happy users. Never scroll in two directions because it jolts the user in to having to work out if where they are going and what they are doing. One dimension only.<br />
<br />
Always choose to put more information on a screen and let it be scrolled rather than asking the user to page.<br />
<br />
<br />
<b>Minimalism over Sensory Overload</b><br />
Flat design is the word of the moment, although it has been around and had requests for seconds since well before iOS7. Even Microsoft pushed for minimalism in Visual Studio 2012 onwards, to the astonishment and even disgust of some devs.<br />
<br />
Developers, especially front-end focussed ones, still tend to lean towards bringing the richness of dedicated clients to the web. Instead, the current trend is to bring usability and simplicity to the web so that mobile users are not fighting the animations and over-populated screens to get what they want done.<br />
<br />
If you can make it simple then do. No one is impressed with the equivalent of a 1997 HTML blink tag when they can look at a clean screen and find what they want with not too much mental effort.<br />
<br />
<br />
Remember those three guiding principles and you can start moving in the right direction, if you aren't already thinking this way.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-19939949625173624312014-04-07T21:41:00.000+10:002014-04-07T21:42:06.670+10:00Define Done<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDUUpuKnRTlMfwFAVczhRgrRQ8ksE2iJwGbXbbt_xgOhkl1wQFZ0ngGUZgf-a4DwfB1Xw6nvsmgBctoGBLMmFOWW98LTw_oiT1d9nT1FrwW2qhUdK2UbtF-2-8notXT_l-IyXswVu3yCY/s1600/Done.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDUUpuKnRTlMfwFAVczhRgrRQ8ksE2iJwGbXbbt_xgOhkl1wQFZ0ngGUZgf-a4DwfB1Xw6nvsmgBctoGBLMmFOWW98LTw_oiT1d9nT1FrwW2qhUdK2UbtF-2-8notXT_l-IyXswVu3yCY/s1600/Done.jpg" height="176" width="320" /></a></div>
<br />
<br />
Often when I read blog posts or articles about agile, they are talking about advanced concepts or solving funky problems that happen when you're in the depths of running an agile team.<br />
<br />
The alternative are Masters of whatever flavour of agile is in at the moment. They are saying you start by following these exact rules that will save your whole team. I call bullshit on all of them.<br />
<br />
In a<a href="http://geekdamana.blogspot.com.au/2014/03/forget-being-lean-until-you-get-some.html"> previous post,</a> I spoke about how there is no point is applying an agile band-aid if you don't work out where you are first and then add rigour to your current processes.<br />
<br />
Once you do work out what practices your team is using and identify them and apply rigour, it is time to start putting in place some entry and exit criteria to initiate work and define success. I consider it drawing two lines in the sand that represent where we start and where we finish.<br />
<br />
I always start with multiple <b>Definitions of Done</b> that apply to sprint tasks/stories, the entire sprint/iteration and the project.<br />
<br />
This gives the whole team an idea of what it means to have completed a task and signed it off. That doesn't mean you comply with full continuous deployment and produce production releases at the end of each sprint (although we all dream of such a utopia) but it does mean that you have an end state that is achievable and universally understood. Working software is of course, part of this end goal.<br />
<br />
It is important that this is understood before you even start the project so get this in place and get buy-in before you seriously put in any delivery effort.<br />
<br />
<b>Definition of Done for a User Story</b><br />
I often treat the definition of done for a user story as the exit criteria for the swim lanes on a <a href="http://www.kanbanblog.com/explained/">Kanban</a> board. This defines when a user story that fits in a sprint is considered complete:<br />
<br />
<ul>
<li>Business analysis is complete [Owner: Business Analyst][Swim lane: In Analysis];</li>
<li>Technical analysis is complete [Owner: Technical Lead][Swim lane: Ready for Dev];</li>
<li>Estimation of effort [Owner: Entire delivery team][Swim lane: Ready for Dev];</li>
<li>Implementation of the user story is complete [Owner: Developer][Swim lane: In Dev];</li>
<li>Implementation of unit and integration tests [Owner: Developer][Swim lane: In Dev];</li>
<li>Integration with all other sprint stories [Owner: Developer via Continuous Integration][Swim lane: In Dev];</li>
<li>Automated packaging [ Owner: Developer][Swim lane: In Dev];</li>
<li>Automated or manual deployment [Owner: Developer and Tester][Swim lane: Ready for Test];</li>
<li>Full functional testing in a partially integrated environment where mocks are allowed [Owner: Tester][Swim lane: In Test];</li>
<li>Sign-off of user story functionality, confirming implementation reconciles to requirements [Owner: Tester][Swim lane: Ready for Sign-Off]; and</li>
<li>Sign-off from product owner that the user story has been delivered [Owner: Product Owner][Swim lane: Signed Off]</li>
</ul>
<div>
<b>Definition of Done for a Sprint</b></div>
<div>
A sprint is considered done when:</div>
<div>
<ul>
<li>Sprint planning was run and included the whole team;</li>
<li>All user stories are signed-off by business;</li>
<li>All user stories have been fully integrated with the current working software;</li>
<li>Automated test coverage meets the agreed team standard;</li>
<li>A retrospective has been run and actions owned or implemented by owners;</li>
<li>Backlog has been groomed for future sprints;</li>
<li>A deployable package has been prepared and versioned for release to an acceptance environment (that may be production); and</li>
<li>Actual versus Estimated Velocity has been compared for future planning.</li>
</ul>
<div>
<b>Definition of Done for a Project</b></div>
</div>
<div>
This is a much tougher one. It depends on the situation you are in and the environment. Often we aim for working software and successfully full requirements reconciliation. There are many other things though that make this list. It is one that must be agreed to prior to delivering the project.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
The important thing about any definition of done is that you must know up front what the goal posts are defined to be and not move them. Yes, you can change the way you play the game but you still know what it means to be finished.</div>
<div>
<br /></div>
<div>
Don't start until you know what it means to finish.</div>
<div>
<br /></div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-85710677829213961442014-03-31T23:30:00.000+11:002014-04-01T05:01:11.526+11:00Don't Be A Jerk<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxHG8bRH4teo4xHY7-R27sqLGvJHT10ZpqlodOoJdRIdYeQGWF1f9x9PgYvTGzfqH_HlOIuSR_WopxP_iH5mDqcnB3cjC3I-j2Sa_JIezXkP7-F_H5e6-ow1LuZ6fVOYTJ5Hj2mdFKb0Y/s1600/No-Jerks-Allowed-Mark-post1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxHG8bRH4teo4xHY7-R27sqLGvJHT10ZpqlodOoJdRIdYeQGWF1f9x9PgYvTGzfqH_HlOIuSR_WopxP_iH5mDqcnB3cjC3I-j2Sa_JIezXkP7-F_H5e6-ow1LuZ6fVOYTJ5Hj2mdFKb0Y/s1600/No-Jerks-Allowed-Mark-post1.jpg" height="159" width="320" /></a></div>
<br />
<br />
In 2006, Joel Spolsky wrote <a href="http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html">a revealing blog post</a> about how his company FogBugz hired staff. There were a lot of great insights about having strong firing policies to match your hiring policies.<br />
<br />
He talked about technical skill and all sorts of stuff but the one thing that stuck with me was one line that reinforced my view of the world and myself: " Even before we started the company, we realized that we should add a third rule: 'Not a jerk.' "<br />
<br />
I have worked with thousands of people now as a contractor, consultant and researcher.<br />
<br />
Through the years, I have seen people who I would quite willingly call genius. Brilliant beyond what us mere mortals can call smart. Above the intellect of the most intellectual intellectuals. I am not one of them. They are often so aloft when it comes to perception that the rest of us look like ants on the dirt.<br />
<br />
The thing is that I have also worked with very smart people. Not someone to be tagged with genius but very smart. Architects. ThoughtWorkers. Just smart people.<br />
<br />
Over and over again, I have come to one conclusion when I build teams. I don't want to work with jerks. No matter how smart you are. No matter your skills or your gansta gains, there is nothing that would make me pick a pretty good team player with above average skills over genius who solved everything.<br />
<br />
The way I see it, if I have to be stuck on a desert island with you forever building a hut or a raft or cooking the same old fish and bark we have eaten for months then I want to like you.<br />
<br />
We are but people. We want to want to be at work if we must. If there are 40 hours of our 112 waking moments then I want to volunteer to be there with others.<br />
<br />
Nice people make that possible.<br />
<br />
What Joel was saying in his vast wisdom is that you have to choose good people but they have to be good people. I'd forgo your brilliance for someone who can gel with the group. I'd give up that insight for someone who was above good but liked people. And if you don't get that then you shouldn't come work with me.<br />
<br />
Mean people are blockers.<br />
<br />
Hire good people who get shit done and aren't jerks.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-21900467482137987532014-03-23T23:41:00.000+11:002014-03-23T23:41:55.114+11:00Forget Being Lean Until You Get Some Rigour<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFkdBNQSxHu3R6QePmgmgVM4Fh0l747aOFeqKQLp6UC9CQqkSWjO6ogAshmFMBhg_j8iIdWcsS4FUP93FA14W9-2m8od475-rkSbxNqJPyawoLyrH8fGjMgAxZgonpXOtKcAFdr85FFwA/s1600/how-to-remove-fat-from-meat-1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFkdBNQSxHu3R6QePmgmgVM4Fh0l747aOFeqKQLp6UC9CQqkSWjO6ogAshmFMBhg_j8iIdWcsS4FUP93FA14W9-2m8od475-rkSbxNqJPyawoLyrH8fGjMgAxZgonpXOtKcAFdr85FFwA/s1600/how-to-remove-fat-from-meat-1.jpg" /></a></div>
<br />
<br />
Over and over again, people talk about <a href="http://www.segla.com.au/Lean-Six-Sigma/?gclid=CMa9jYXSqL0CFQEepQodYBgArQ">Lean</a> like it is a giant waterproof, super-fast healing Band-Aid that will fix every delivery team. They say "Toyota this" and "Motorola that" and "you're not lean enough."<br />
<br />
The problem I have with this is when the Band-Aid is being applied to a delivery team that has no structure at all. You can't make a cowboy team leaner or even more agile without putting structure in place and then improving it.<br />
<br />
I don't mean picking Scrum or Kanban and saying do this and then become leaner. Instead, I mean that teams must become aware of their as-is way of functioning. Identify practices and articulate them. There always are practices in place but people are not always conscious of them. Without consciousness, there is no method. Once you have method, you can use it rigourously.<br />
<br />
Become aware of what you do now. Decide on where you want to be. Map a course of action from one to the other and most importantly, give yourself time and give yourself permission to fail and correct.<br />
<br />
Telling a team with no self-awareness to become leaner is pointless. First find the point.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com1tag:blogger.com,1999:blog-2144813210603379421.post-28554012594188777872014-03-23T23:10:00.000+11:002014-03-23T23:10:13.822+11:00Agile - Is it only mostly dead?<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.imdb.com/title/tt0093779/"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiD6P4LM4pC0CfXF7OmXJs91dpWrqh_bKrNwWqZg71o2f_J6wZTaGQCNEdf-Q8fok5ZtL7T-a9RbkwCyTGwOTFYlprcr83qMykpNj3579DivYRttQWZYEoviXD5ER5fmdUsYgdrHUOJ7Hs/s1600/mostly-dead.jpg" height="176" width="320" /></a></div>
<br />
One of the fathers of the Agile Manifesto, <a href="http://en.wikipedia.org/wiki/Dave_Thomas_(programmer)">Dave Thomas</a> (@pragdave) wrote a blog post a couple of weeks ago proclaiming that "<a href="http://pragdave.me/blog/2014/03/04/time-to-kill-agile/">Agile Is Dead (Long Live Agility)</a>."<br />
<br />
The post has been moving through the software dev community and causing much head nodding. Everyone seems to agree that the word "agile" means very little these days and has been corrupted by the trainers who will make you a Master from a two day training course for thousands of dollars.<br />
<br />
At ThoughtWorks, we would mostly snigger at people who called themselves Scrum Masters but not because they were so quickly empowered. It was more because they missed the point of being agile and instead adopted prescriptive processes and accompanying costly tools to achieve what can be done with much less and achieve much more.<br />
<br />
The reason that I am happy Prag Dave spoke out and voiced this is because people will hear it now.<br />
<br />
Being agile is a way of thinking and acting and not a set of hard and fast rules that make better software. Tools and processes won't save a team. Pragmatism, rigour and constant feedback with change will.<br />
<br />
I don't know if the word "agile" is dead. The good thing is that a lot of us agree that we need to be more agile and not do agile.<br />
<br />
So go do that already.<br />
<br />
<br />Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-89948897051842638492013-12-30T03:04:00.002+11:002013-12-30T03:05:41.251+11:00Stop writing your own frameworks<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/torsten04/8929819272/"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkykAQEAvOJpjQkcbyQ-1_bmA18upkr6mjfXOGn0vdQoTwwJYMJFaDQnCJC-i_uTbag4ILrgiJNcug1xFz4bsFNbzj-T9jiW6guFPkCIafNItpqJIZT4ybxgEttLU16MieZMXhEA85oeM/s320/empire.jpg" width="320" /></a></div>
<br />
<br />
I am in Darwin for Christmas. This is where I grew up, went to University and came back to work for a very short time in 2010 while trying to work out whether I wanted to stay and face the challenges of my profession.<br />
<br />
It was very a short stay because this place is like many small Australian cities - there is a need for IT but it is satisfied by a small pond populated by a lot of medium-sized fish acting like sharks. After a very short time, <b><i>that</i></b> gets old.<br />
<br />
My career is about focussing on building software that people want to use, not flexing my under-developed biceps and splashing wildly in a muddy pond. So while I was here, I did my best to learn something from the situation and not cause too many ripples. Yeah, me... the ripple maker.<br />
<br />
As I walked in to different clients, developers on the client-sites kept asking me what frameworks I had brought with me. At first, I smiled and said .NET but then I realised they meant bespoke frameworks that I had created. They wanted to know what I carried in a swag on my portable hard drive that helped me build systems. In their case, this was for small systems of simple client-sever apps. And every dev had their own framework.<br />
<br />
You're probably wondering what I mean by a small system. In the context of software, it is a system that services a small number of concurrent users and does not require capabilities like scalability and robustness under load. Yes, yes, you may argue all systems do but for more affordable systems with simple requirements that change infrequently, this can seem like over-kill. The developers who build these know that they are coding write-once applications. So the bits they do find themselves repeating on the next project, they build reusable frameworks for. These frameworks can then be used over and over again as they build the same designs over and over again. Reuse. Good, right? University told us reuse is good.<br />
<br />
This is not that different to what I have seen in a lot of medium to large organisations though. It seems more common in groups that build small systems but it does cross all worlds and all demands. The difference is that the big places don't ask for my custom framework. They instead tell me about theirs.<br />
<br />
<h3>
The Problem With Your Custom Framework</h3>
<div>
<br /></div>
Every time you build software, you should regress to the point of origin: The Requirements.<br />
<br />
Every piece of software you implement. Every line of code you write. Every ounce of effort you exert in making the machine grind should be traced back to a requirement that a user needs in order to achieve their goal while using the software.<br />
<br />
If you've worked with me then you still have my voice in your head droning on about the importance of <i>requirements traceability</i>. For the rest, expect a blog post in the very near future.<br />
<br />
Custom frameworks are not an exception to this rule. In fact, they are the one part of any system that should be justified to <a href="http://www.urbandictionary.com/define.php?term=kingdom%20come">kingdom come</a>. If you can't find a business reason to build it then don't. I have very few to no exceptions to this rule.<br />
<br />
Now, the reason this is important is because software has to be maintained. It must be extensible, robust, reusable, testable and above all else relevant. The software should never be held back by the tools and materials used to build it. They are not important. The end-user software is.<br />
<br />
If the requirement of your job is to build software that other software uses to satisfies its requirements then framework away. If not, then you will spend a lot of upfront effort and infinite future work maintaining your framework just to keep it relevant to the systems it consumes.<br />
<br />
People like Microsoft have many teams of many elite developers building many generic frameworks for you to build your castles upon. Unlike the sand that yours will be built of, theirs are backwards compatible, constantly updated and relevant. All you have to do is recompile or re-consume their changes and keep focussing on your business needs. You focussing on supporting multiple systems and stalling natural evolution and progression is more detrimental than helpful.<br />
<br />
In most cases, there are two reasons developers insist on building their own frameworks. The first is that they took what they were told at university about reusability to mean that they must reuse code or they have failed. The truth is that design patterns are more reusable than code in a lot of circumstances. If you do need code reuse for one system, it will not often translate to another system unless great care is taken in the first place to design it that way and the agreement to maintain it is consciously agreed to by all parties including business.<br />
<br />
The second reason is that developers like to build stuff that they can point at and say they built. I think this is sad and verging on the point of needy. As far as I am concerned, I should be able to look at a code base and have no idea at all what each developer wrote. Code is not about a developer tagging the mountain of obfuscated code that represents their prowess to others. It is about making something that can exist long after your are gone.<br />
<br />
Let the nicest thing anyone said about you be that your code was clean, correct and easy to understand.<br />
<br />
<h3>
How To Know Your Framework Is Holding You Back</h3>
<div>
<br /></div>
If you spend a lot of time working on your framework and not on features then your framework is not helping.<br />
<br />
If you spend time justifying why systems dependent on your framework can't be advanced to later versions of general software (like newer version of .NET) then your framework is not helping.<br />
<br />
If you write a new system with exactly the same design as the last system then you must ask yourself if you are solving the problem domain or complying with the saying that if all you have is a hammer then everything looks like a nail.<br />
<br />
<b>So You're Saying My Framework Should Be Thrown Away?!</b><br />
<br />
Yes.<br />
<br />
Most frameworks are built to satisfy a need that an underlying framework (like .NET) does not yet satisfy. As soon as that general framework does, you should deprecate your compensation.<br />
<br />
Stop wasting your time working out the best way to forge steel and instead buy it from the great steel works and then go about constructing great structures.<br />
<br />
I'd much rather build the Empire State Building upon the shoulders of others than a half good piece of metal alloy that may or may not support a bridge tomorrow.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com1tag:blogger.com,1999:blog-2144813210603379421.post-66295570110355479452013-11-27T22:39:00.000+11:002013-11-28T12:41:25.919+11:00Stand-Up or Scrum Etiquette<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-x-hXluLXE0ZLg1mxh9By9bwkJ6OdbMFSgVecDTpho50ECv13sjNWz4-2bQ0difHDwkYKVrDQOePEM2XdUcVqhX8LU3mNvo4n1ESoPhYFbdyqKrvAekmOH6XQzuyA0Vg2Xsxeym31fC8/s1600/scrum_rugby.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-x-hXluLXE0ZLg1mxh9By9bwkJ6OdbMFSgVecDTpho50ECv13sjNWz4-2bQ0difHDwkYKVrDQOePEM2XdUcVqhX8LU3mNvo4n1ESoPhYFbdyqKrvAekmOH6XQzuyA0Vg2Xsxeym31fC8/s320/scrum_rugby.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
My new role is on a team that has a scrum with almost 20 participants. At this point, it is important to obey the ethos of a scrum (or stand-up) or there is a potential to waste the time of many people.</div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
Here is my basic <span class="">Scrum</span> <span class="">Etiquette</span>. It is good to remind people of it at the beginning of a scrum at the beginning of a new sprint or when things are out of control.</div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
Scrum<span class=""> </span>Etiquette:</div>
<ul class="" style="color: #222222; font-family: arial; font-size: small;">
<li class="">Turn up on time. The <span class="">scrum</span> will start without you;</li>
<li class="">If you can not attend the <span class="">scrum</span> then give someone your update and they will go through it on your behalf;</li>
<li class="">Your update should consist of… 1) What I've done since the last <span class="">scrum</span>. 2) What I'll do between now and the next <span class="">scrum</span>. 3) Any blockers;</li>
<li class="">Your update should take about 30 seconds;</li>
<li class="">All other conversations should take place after the <span class="">scrum</span> in a Dev Huddle (for tech talk) or BA Huddle or Tester Huddle or specific delivery teams; and</li>
<li class="">Speak to the team and not just the <span class="">scrum</span> master. It's about sharing with your whole team and not just reporting your status to the boss.</li>
</ul>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
<span class="">Scrum</span> Anti-Patterns (for the <span class="">Scrum</span> Master to look for when running the <span class="">scrum</span>):</div>
<ul class="" style="color: #222222; font-family: arial; font-size: small;">
<li class="">More than one person acting as the <span class="">scrum</span> master;</li>
<li class="">Everyone speaking to the <span class="">scrum</span> master;</li>
<li class="">Long updates with too much detail;</li>
<li class="">Technical discussions that other team members aren't interested in;</li>
<li class="">People not mentioning blockers. People should explicitly state if they have no blockers; and</li>
<li class="">People looking uninterested.</li>
</ul>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
I did google this and there weren't enough clear definitions. Every team is different and you will adjust to yours. This is a good starting point.</div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div class="" style="color: #222222; font-family: arial; font-size: small;">
Go forth and scrum.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-4718131109409572032013-11-13T22:59:00.002+11:002013-11-13T23:21:37.292+11:00Your compiler is your friend<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/damana/9672085402/"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVBXaH_SQr7gd_MMlyrTIgAS8c1xIgVIcq0htI4CnGINsZVGSoIp1aQbuyM3ECiKAIQtWlOKzRt4gQ8YvGi0kWKdg6DyZmdVo5liR2DoCZ50cnEwHWFZ9o0Js-YR5Qytf9jdV7pPjJmWU/s320/9672085402_70ea28f298_z.jpg" width="240" /></a></div>
<br />
<br />
Today, I spent a small amount of time helping a developer solve a problem.<br />
<br />
That may be how I start a lot of my posts for a while since I am working with some smart chaps who are learning to be better devs. The thing about learning to be a better developer is that you learn it from writing a helluva lot of code and from working with old grey haired devs like me.<br />
<br />
Ok, I don't have grey hair but I do this wise Gandalf voice that really deserves some grey hair.<br />
<br />
When I started developing, a compiler wasn't much without a linker. We spoke of lint and didn't mean the stuff left in driers. We had pet dinosaurs.<br />
<br />
One thing that understanding the parts that come together to be the <b><i>Build</i></b> that we all speak of now is that we learnt to listen to what each part was telling us. No, no, I don't want you to go out and conduct some native American dreaming ceremony but I do want you to listen to your compiler warnings.<br />
<br />
In today's adventure, I paired with a developer who was having issues adding a set of XSD schemas to a .NET schema collection. The thing is that this class was deprecated after .NET 2.0 and the reader feeding it was also of the past.<br />
<br />
The compiler told us so.<br />
<br />
The thing is that although many developers are warned over and over again that they are using an old API function and to use X instead, they persist. They ignore that and many other warnings. This however is the most common one I see outside of warnings about variables being initialised but not used.<br />
<br />
Your compiler is telling you this for a reason. It isn't because it has had a slow day or it is having a grumpy moment. No, it consistently warns you that there is a better way to do things now and even suggests how you should attempt this.<br />
<br />
So, we solved our issue today by listening to the warnings and using the latest and greatest (be it 3 years old) and all was well.<br />
<br />
Yes, we have evolved as a profession to obey our build errors and not check in a broken build to avoid the hisses and boos of our colleagues. Now we must grow to listen to the warnings. They are not wasted cigarette lighters at a Pink Floyd concert. They are not a gasp of exclamation in a sea of squealing teenage girls at a boy band concert. They are not platform high heels at a Kylie Minogue concert. No.<br />
<br />
To be a better developer, you will listen to the advice you get from your build, your static code analysis and your IDE refactoring suggestions. You will do it because it will make your code better and more up to date. You will do it because it will stop the bad things happening that happened to those before you. You will do it because it will stop my soul from hurting.<br />
<br />
Be it Visual Studio or IntelliSilly, your IDE is your friend. Your compiler warns that there be dragons and you must listen.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-71327366139689568232013-11-12T01:54:00.000+11:002013-11-13T23:20:33.417+11:00We Are So Progressive<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/jgarber/146565226"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4jy0lxcCk0RH4C17ITMakyjzS6WV0RG3RdLOWsH-_vrerxKPiy73dk53ijK2DRTtZVKPeR-6BXdj47N25T2U9ed287Jc0MRNyCzI-P0t2IlyFsqLF9MsDKI72Fk5ErgJe-KhyphenhyphenRWlLoIU/s320/baby+steps.jpg" width="320" /></a></div>
<br />
<br />
While waiting for my clearance to clear (that's all for another blog post), I've been talking to different people about short term gigs. I am not in any major hurry to find anything so the conversations are not stressful job interview types but more a chat about whether we can work together.<br />
<br />
One interview was such an entertaining conversation that I was impressed at my ability to keep a straight face the entire time. Instead of giving you a blow-by-blow of the whole session, I'll just share the top three highlights that made me smile afterwards.<br />
<br />
<b>"I don't believe in unit testing. It gives people a false sense of security. I believe testing gets in the way, which is why we fired the dedicated testing team."</b><br />
<br />
This came out of me asking what the automation in their dev and deploy processes is like and what kinds of testing (automated and manual) were in place. The development manager and architect (who is the same person) went on to lecture me on the false security blanket that unit testing is and that it is an overhead that in no way helps assure a quality code base. He used words like <i>coverage</i> and <i>feedback loop </i>and other buzzwords but not in any way that seemed to fit in with any kind of practices or processes I'd ever heard. It's very possible I was hearing of very new ideas. Yeah, possible.<br />
<br />
In the end, he had reduced his delivery team to a business analyst and a bunch of developers who pushed code through to Production in 20 minutes with his surety and trust that they simply didn't write buggy code.<br />
<br />
<b><br /></b>
<b>"We have Continuous Integration right there. *points at monitor hanging on wall* That screen shows our 16 production apps. It pings them every few minutes to see if they are still working. If they are, it's green. If they aren't then they appear red."</b><br />
<br />
Now, that is a dashboard but it in itself is not CI. I've been seeing the term Continuous Integration used a lot of by people who think it is based on red and green lights. I'm guessing the amber light of traffic lights must make them really confused.<br />
<br />
In this case, I asked if they had any automation around their build or deploy process. Again, I was dismissed as some kind of charlatan with ideas from yesteryear. This was the point where I became most distressed, in that burning-building-and-the-lifts-are-out-and-I'm-on-the-75th-floor kind of way.<br />
<br />
The dev manager said that "yes, our profession is going towards automated testing but that's a phase." He said he was going away from it having proved it wrong. He said "I am progressive." After later whinging to some ThoughtWorkers, we decided he was progressing backwards and so was technically correct. *sigh*<br />
<br />
<b>"Data modelling is over-kill."</b><br />
<br />
Now, I'm the kind of girl who watches Fast and Furious 6 and thinks there weren't enough car scenes. I even read reddit and wonder why the comments ended. Over-kill is not something I claim or proclaim much at all.<br />
<br />
In this case, he (dev manager guy) wanted to know what I liked about ASP.NET MVC. He wanted to make sure I hadn't just read the FAQ. I just spent the last 18 months as the Microsoft PFE ASP.NET MVC Lead in Asia so when I say I know MVC, I wrote the FAQ. Either way, test away.<br />
<br />
I gave my reasons and went on to talk about DDD and the merits of building a domain true to your users. He sniggered. That's ok. People snigger.<br />
<br />
In this case, he challenged every idea of modelling to the point that he said he'd discarded Entity and any persistence layer at all and thought a Dataset passed straight to the templating engine wasn't awful.<br />
<br />
I sighed again.<br />
<br />
<br />
So those were my favourites. I commend myself on my ability to listen and consider all that was said. Even his <i>impressive</i> 20 000 requests on his 16 web applications per day had me keeping a straight face. Ask any of my colleagues who've worked on farms that do that in a second. Oh well.<br />
<br />
One thing I took from this whole experience is that everyone has a world that seems huge to them. What we must learn is how to judge up and out. There are people out there who don't want a pissing contest. They just want to help you build software that scales, is robust and can be extended.<br />
<br />
In my world, I always want to strive to work in better places that teach me bigger and more amazing concepts. Everything I know is tiny and insignificant compared to what I have to learn.<br />
<br />
At least, I know that.Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-16184660222631347962013-09-03T00:54:00.002+10:002013-09-03T00:55:43.027+10:00Agile - Start with paper walls<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/smorked/2096018330/in/photostream/"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvtrarNbQCc6jYsrU-QZsoCmxzS8z55vQjizwWANbwIUbwouhN3ua_Iu-T3_eQ6i6YdYcUZ6rFAbRVzVgnyJrFMdEPNyXCBTiTzIstepDSW_HXzAt2xTgRiPz5QuhY6lHQEYMDwXgqQpQ/s320/paper+walls.jpg" width="320" /></a></div>
<br />
<br />
Clients often come to me to ask how they should set up their instance of <a href="http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx">TFS</a> <a href="http://msdn.microsoft.com/en-us/library/fda2bad5.aspx">ALM</a> so that it will reflect their software development lifecycle.<br />
<br />
My usual response is a question: What is your software development lifecycle?<br />
<br />
Now, that is actually quite difficult to answer for most developers and development team managers.<br />
<br />
Most people either say waterfall or agile.<br />
<br />
It is rarely waterfallers who are asking for more process or tools. It is usually the neo-agilistas who want imposed structure . Everyone is doing agile or they did it once and it didn't work.<br />
<br />
There are many tools out there promising to agilify your software development "process".<br />
<br />
They will promise that it doesn't matter what standard your developers are at because the tool will raise them up.<br />
<br />
They will promise that it doesn't matter if all you've ever done is waterfall with an avalanche of specifications and documentation because you can just stop doing that.<br />
<br />
They will promise that if you sign with a little blood then everything you do will be faster, better and leap buildings in a single bound.<br />
<br />
Let me tell you honestly and with great confidence that there is no software tool on the market that will do any or all those things for you.<br />
<br />
Spending thousands of hours building, mentoring and empowering agile teams has taught me three very important immutable facts:<br />
<br />
<ol>
<li>You need to train your teams to be agile and that can only be done by introducing experienced agile coaches;</li>
<li>No tools will ever save you. Tools will aid you in recording and tracking your progress but they will not set that progress in motion or maintain its momentum; and</li>
<li>Communication and transparency are the keys to building great software, which means your teams must talk, you must talk to your business who set the requirements and you must be honest about what works and what doesn't.</li>
</ol>
<div>
When I start an agile team from scratch, I start with a bunch of cards, some Sharpies and a will to encourage people to talk to each other by creating a safe working environment.</div>
<div>
<br /></div>
<div>
Jira or TFS ALM or whatever silver bullet you have been promised is nothing if it isn't accompanied by experienced agile practitioners and an acceptance that you will learn along the way.</div>
<div>
<br /></div>
<div>
Start with paper walls and good people.</div>
</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com2tag:blogger.com,1999:blog-2144813210603379421.post-48254579111869759802013-09-02T21:38:00.000+10:002013-09-02T21:38:17.535+10:00Canberra Developer Blogs<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/AVvXsEiohv80_BcgHAEguMcEzLd0EinEpiNIQp6jmtrozzIuCYiN9Yw2TehDgVAA1-Pr93pCSkd2pM37q5UWzwrohCA_d3s2SlAyXXsOmJ27iy6lW5BWFkE_xO38SQV-pwiJwTSlcn00tXpxIMM/s1600/blog.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiohv80_BcgHAEguMcEzLd0EinEpiNIQp6jmtrozzIuCYiN9Yw2TehDgVAA1-Pr93pCSkd2pM37q5UWzwrohCA_d3s2SlAyXXsOmJ27iy6lW5BWFkE_xO38SQV-pwiJwTSlcn00tXpxIMM/s320/blog.jpeg" width="320" /></a></div>
<br />
<br />
These are the Canberra developer blogs that I have gathered so far. This list will be updated as I find more. Here is the list:<br />
<br />
<br />
<ul>
<li><a href="http://blog.brianfarnhill.com/">Brian Farnhill</a> blogs, speaks and knows about SharePoint;</li>
<li>Dale Anderson writes <a href="http://www.danderson00.com/">The Ravings of a Software Engineer</a> . He is the author of the <a href="http://tribejs.com/">Tribe platform</a>;</li>
<li><a href="http://pipka.org/">Pia Waugh</a> is an open government and open data ninja who is freeing federal data;</li>
<li><a href="http://www.prd-software.com/">Rod Weir and his team</a> produce software for helpdesk and support services;</li>
<li><a href="http://maxblogson.net/">Manickam Ramanathan</a> is a passionately curious .NET developer;</li>
<li><a href="http://jeffstechstuff.blogspot.com.au/">Jeff Lau</a> is a Java dev with good insights for all devs; and</li>
<li><a href="http://geekdamana.blogspot.com/">Damana Madden</a> is me. I am a .NET developer with a tendency to code in lots of different non-Microsoft languages but C# has my heart.</li>
</ul>
<br />
<br />
<br />Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-57780101680499406372013-06-23T23:56:00.002+10:002013-07-06T00:13:20.701+10:00Visual Studio Tricks - UML Validation of your Intended Architecture<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/rvoegtli/5688343678/in/photostream/"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivakJ8jzq_cESK5CjcCTXxcWHARfhzuxXLd0OJws14RD6grKSY5_Vc7A49b__zQO2CxWF9mPY179Pobrvu1QH3vf_9oupK5FkxhU5GXlbdpIuRMLCJFyPmgQOZvYFZPzIRQXcbL5UAifk/s320/Onion.jpg" width="320" /></a></div>
<br />
<br />
Now for the third post from the series of <i>Visual Studio Tools I Can't Live Without</i> on using UML diagrams to validate your intended architecture.<br />
<br />
Part of what I do when I run a code review is to extend it with a report on design divergence. That is when I look at what the intended application design was and what has actually been implemented.<br />
<br />
This takes several long and probing interviews with the application architect or technical lead, asking questions about what they think has been coded. Then I look at the code at a high level, with more attention paid to sections with more complexity.<br />
<br />
Sometimes it is pretty spot on. Sometimes it is very very different when we get in to the code.<br />
<br />
As mentioned in other posts, I will use tools like <a href="http://geekdamana.blogspot.com.au/2013/06/visual-studio-tricks-dependency-graphs.html">dependency graphs</a> to get a quick high level understanding of a code base. Another tool that Visual Studio gives me that I didn't have in the past is UML diagram validation of code.<br />
<br />
Visual Studio has a project type called a <a href="http://msdn.microsoft.com/en-us/library/vstudio/dd409445.aspx">Modelling Project</a> that allows you to create different kinds of UML diagrams that communicate what your intended application design is or are created from code and show the implemented application design.<br />
<br />
Again, there is a lot of <a href="http://msdn.microsoft.com/en-us/library/vstudio/dd418995.aspx">documentation</a> on how to create these <a href="http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Using-layer-diagrams-to-design-and-validate-your-architecture">diagrams</a>. The main thing to know is that there are many different types of diagrams and once you put them in place, they can be used to validate the actual code.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8WxeXOO97-PM0UkhKq8WyLAwjejs5UNbfiiwQ4IYdB7SEngtW4Pv96dba5xuh_2OU6MLAv1u-oIf7UR7jpHVH-cC40WsoNPSEo-fcYtu-AAKbbv166NYNZT3EYZCmSBz-V3sUbF9V5Rw/s1600/UML+Diagrams.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="275" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8WxeXOO97-PM0UkhKq8WyLAwjejs5UNbfiiwQ4IYdB7SEngtW4Pv96dba5xuh_2OU6MLAv1u-oIf7UR7jpHVH-cC40WsoNPSEo-fcYtu-AAKbbv166NYNZT3EYZCmSBz-V3sUbF9V5Rw/s400/UML+Diagrams.jpg" width="400" /></a></div>
<br />
Using these tools, you can reverse engineer a code base quite quickly and take in the high level design visually, which is for me the fastest way to understand an application architecture.<br />
<br />
It is also quite revealing in that it can show boundary violations between components that cause future extensibility pain. In one case, we identified calls being made from the view directly to the data access layer, bypassing business logic layers. The architect there didn't realise that some of the less experienced developers didn't know they shouldn't do things like that. <br />
<br />
Layer and <a href="http://msdn.microsoft.com/en-us/library/33864ckt.aspx">Class</a> diagrams are my favourites. The ability to drag and drop a file from the Solution Explorer in to the diagram makes them a breeze to create.<br />
<br />
Once I have diagrams in place, I communicate to the technical leads how to continue to use and create them for regular checks and even in gated check-ins.<br />
<br />
A picture really is worth a thousand words. <br />
<br />
<br /></div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-49508743129632825492013-06-20T23:58:00.001+10:002013-07-06T01:01:34.709+10:00Visual Studio Tricks - Dependency Graphs <div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/curtsm/283309601/in/photolist-r335i-9G9fkf-6LfvDf-7tnTKo-5tj1DG-aHhna6-74pw1x-51ycz-8ognYs-bHF2p8-by4QTf-8pUf6j-8pR63i-8pUftb-8pUfAy-8pR51n-mYCVp-5rt3fu-b4tLMZ-decd6C-4Vc9mt-4VgnTS-7akPi-8wdQHN-6MbiRf-jG4wh-77fRLZ-7ryjsJ-5roEwn-5roAqX-5roBTv-aqKQGv-4rhGUq-dk8tvZ-euCpq3-b8K8Pi-316yCg-31b4TG-31b64m-31bdvo-31b56W-316H2Z-316xNt-316EZD-316A4H-31bfxS-31bfjQ-31bdfJ-316z6p-316w2a-31bbq9/"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiN9MNlpXikIyPtbAuVyJI8RC-VsRnWRf7OgGIrGezNCn7HSVyOJ_AMhfAPyu4i2VZQ3hUG5IL6KoZP3JD5EveffHRkiWQM_PGS3VC-YCijYXOPb8pWO-aGsFoYSob9jHJBU37DqKF3I2g/s320/nodes.jpg" width="320" /></a></div>
<br />
<br />
In the second post of this series of <i>Visual Studio Tools I Can't Live Without</i> are <a href="http://msdn.microsoft.com/en-US/library/vstudio/dd409453.aspx">Dependency Graphs</a>.<br />
<br />
When I conduct a code review or set up a gated check-in, static code analysis will give a list of all the things that are wrong based on a predetermined set of recommended practices. These are mostly superficial and not 100% indicative of whether a code base is bad or terrible or should be burnt to the ground.<br />
<br />
Usually, people will look at the number of of errors and warnings found by static analysis to draw conclusions. These can often be the same issue over and over due to things like <a href="http://geekdamana.blogspot.com.au/2013/06/visual-studio-tricks-code-clone.html">copy and pasted code</a>, generated code or agreed practices that counter recommended practices.<br />
<br />
In any code review I carry out, there is more than just a list of errors. There is an understanding of where those errors sit in the the scheme of things, how serious they are and if they are an indication of worse things to come.<br />
<br />
To draw theses kinds of damning or freeing conclusions, an engineer must understand the code base. We have only days to get to this point so we draw on everything we can to help us with understanding what we are judging.<br />
<br />
Years of experience will help.<br />
A walk-through with the technical lead will help.<br />
And a picture that speaks a thousand words will certainly help.<br />
<br />
With Visual Studio 2012 (VS2012), I have embraced and celebrated the idea of Dependency Graphs along with Analyzers.<br />
<br />
There are a lot of <a href="http://msdn.microsoft.com/en-us/library/ee847415%28v=vs.100%29.aspx">instructive posts</a> about <a href="http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Visualize-the-impact-of-a-change">how</a> you go about this. There is no need for me to walk you through it.<br />
<br />
What I do want to do is make you aware that there is a way to look at the complexity in code in a visual way. You can find and explore circular references, unreferenced nodes and hubs which are highly referenced nodes.<br />
<br />
One place this is valuable is in code reviews of pending change sets. VS2012 can filter to just pending changes. This allows a technical lead to ensure that unnecessary complexity is not introduced with bug fixes or added features.<br />
<br />
If you need to understand how your code is connected then use this tool. You may even become dependent.</div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0tag:blogger.com,1999:blog-2144813210603379421.post-19228385704611642512013-06-20T00:37:00.000+10:002013-07-06T01:03:45.075+10:00Visual Studio Tricks - Code Clone Detection<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: left;">
<a href="http://www.flickr.com/photos/kalexanderson/4941952943/in/photolist-8wGNre-58ELza-9hZFUV-6HhZa1-cYY81E-59EkhP-aop8ZC-8qJN2V-8BHGV5-5NTVmt-5fvyCu-9e7YRw-9sb2CM-8sh7v6-aW3hfK-8wySxF-8wyVPB-57TiRq-57Tj7j-8Z3U5e-8Z6XrU-8Z3U4x-8Z6Xsj-8Z6Xp9-8Z6Xoy-8Z3U5R-8Z3U6M-8Z3U2V-4PifQX-4WyRqC-MsAYr-8wyQrK-amWAnk-bKfR5M-bKfUPz-8Z3U1c-8Z6Xny-6Bby8s-6BbQVJ-aXWPfk-8Z3U1K-8Z6XkN-aQq1Ek-8Z3U8g-8Z3TYT-8Z3TZi-8Z3TXT-7UBbpe-6Hvztd-6Hrw34-5B2SCu/"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2hCt-5X5Aa4M2ZSIUT485dQDlT0KZjRHArlej6j22NNkoIQuTa6RTOrTg0aj6vFecnPbmk1ky2fU-rqF6dxT1VRY3SAzWrg2E1JZtdd7CtiFAh9aZIDsX9caSy1ejXanHTBo-SOtUqlw/s320/clones.jpg" width="296" /></a></div>
<br />
<br />
It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of my essential Visual Studio tools that every .NET developer should be aware of. If you already are then avoid me stating the obvious and go read something else.<br />
<br />
Call me Code Review Girl and hand me a cape. In my role, it is common for me to travel the depth and breadth of Asia, Australia and New Zealand to conduct a code review and design divergence checks on very large government and commercial code bases.<br />
<br />
Microsoft has internal tools that let us do that with great ease. This is always where we start. However, we often go further with remediation plans and sit with developers to show them the kind of things we found in their code that need improving. We don't just show them how to fix it but explain why these issues are issues and how they can be tracked down. In my case, I use <a href="http://martinfowler.com/bliki/PairProgrammingMisconceptions.html">pair programming</a> to start. Teach a dev to fish and all that.<br />
<br />
When I pair program with a developer, I will never let them copy and paste code. They can either type the whole thing from scratch or they can write a method and call it in both places. Copy and pasting code is an anti-pattern that will result in bloated code bases and often carried errors.<br />
<br />
Now, that is all well and good when you are writing new code with another developer but for the times when you aren't watching and enforcing that rigour or for past crimes, Visual Studio 2012 gives you <a href="http://msdn.microsoft.com/en-us/library/hh205279.aspx">Code Clone Detection</a>.<br />
<br />
I won't go in to too much detail repeating what the link above explains but I will give you a quick summary of what you get and how to use it.<br />
<br />
Code Clone Detection looks at code statements of 10 or more lines that appear in methods and properties across entire projects or solutions. It works on code with up to 40% of its tokens changed and with statements that have been rearranged.<br />
<br />
There are two ways to use it:<br />
<ol style="text-align: left;">
<li>Highlight a specific piece of code, right-click and choose to <b><span style="font-family: "Courier New",Courier,monospace;">Find Matching Clones in Solution</span></b>; and find that specific code repeated; or</li>
<li>Use the <b><span style="font-family: "Courier New",Courier,monospace;">Analyze </span></b>menu to <span style="font-family: "Courier New",Courier,monospace;"><b>Analyze Solution for Code Clones</b> </span>and find all occurrences of repeated code.</li>
</ol>
There are ways to exclude certain files like generated code and you will want to do that with large generated code bases.<br />
<br />
I find this one of the most useful tools when looking at how to attack a large code base that needs a refactoring machete. This is a tech lead's best friend. Or at least one of them.<br />
<br />
Let the clone wars begin. </div>
Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com3tag:blogger.com,1999:blog-2144813210603379421.post-64186379675365099252013-02-18T22:26:00.001+11:002013-03-31T11:07:58.264+11:00Have you heard of a magical place called the Internet?<div class="separator" style="clear: both; text-align: center;">
<a href="http://xkcd.com/87/"><img border="0" height="217" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg54Eotlnj-nyPfc3MXLra-Kxv_c0Q65Bm_WkBGUrXkAIbJ_rQVpCPCdS2OBrA8Dbn12mVxhRerzOdZshh-YFfHwDX6gFzjFjPuz-z6inCsEF6ssOdZ10-RR2lo1g7YUk88aGBGmcuvU_8/s320/xkcd.jpg" width="320" /></a></div>
<br />
<br />
I am a little bit of a spoiled brat when it comes to the wired world. My web presence started with <a href="http://en.wikipedia.org/wiki/GeoCities">Geocities</a> when we embraced animated gifs and blinking HTML. Then I moved on to pimping MySpace in the mid-noughties and then discovered the pedestal that is having your own blog. Yes, I lived in the even older text based world of newsgroups and spent hours surfing the web with <a href="http://lynx.browser.org/">Lynx</a>.<br />
<br />
These days, I feel sad when I meet "IT people" who think they are somehow carrying a banner of normality by not being on Twitter or Facebook or LinkedIn. They ask "why would I want that?" and to be honest, I couldn't care less that they haven't worked out that the world is leaving them behind.<br />
<br />
In fact, it shocks me to come across "computing people" who snigger at the idea of an online brand only to wonder why no one hires them based on all the silent good deeds they have done. I call that a <a href="http://en.wikipedia.org/wiki/Store_brand">home brand</a>. Yet, they go on to tell me that the world is a meritocracy and no good deed goes unpunished. I don't snigger back.<br />
<br />
In my job, I build bloody big web sites for super large companies. I build mobile line of business apps for multinationals. I build dumb games for smart phones. I talk about design of architecture and of user interface. I demand usability and an enjoyable user experience. I make interacting with the virtual world easier for people who don't spend their whole lives online like I do and for those who do.<br />
<br />
It is unsettling to see the same mistakes being made over and over again. To watch cluttered interfaces be embraced by technologists who I think should know better. To see people tell me that this is the way the world is when I sit in their retro worlds and think of how young I once was when the thing they are championing was actually the new black.<br />
<br />
In the past, I would try to educate them. Explain in detail the reasoning behind good design in visual ways and in code. It would take time and patience and not slapping them but I'd invest and finally help them understand the modern way.<br />
<br />
I'm not even talking cutting edge. Just what is accepted now.<br />
<br />
Everything is different now. Things old people once said to me are now coming out of MY mouth. Things like "I choose which battles to fight these days" and "they will learn in time" and "it is not my job to teach everyone."<br />
<br />
When it comes to a client and delivery at work, I give my all. The long conversations seem worth it. When it is my peers and people I watch or interact with because of work and who aren't my clients then I seem to stand back now. It still irks me or even hurts my soul to not interject but something in me simply doesn't care enough anymore.<br />
<br />
There is this amazing thing called the Internet. Stuff is moving fast. What you understand as the "best practice" or the "standard" may have been that once but it isn't now. I spend so much time looking at better ways to do things and new reasons for doing it that way. That is not an assumption I can make for others.<br />
<br />
Keeping up with progressing technology and ideas is a job on top of your full time job but for those of us in technology, it should be a given. You can't just work 40 hours and go home and base everything on what little you did or learnt in that time. If you want to do that, study ancient history or paleobotany. The world of technology is not the place for you.<br />
<br />
Hey, you kids! Get off my lawn!Damana Maddenhttp://www.blogger.com/profile/00506368430609135921noreply@blogger.com0