tag:blogger.com,1999:blog-83417293822062756622023-01-08T14:37:20.997-05:00AbakasCatherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.comBlogger933125tag:blogger.com,1999:blog-8341729382206275662.post-74475510174256762822013-01-08T16:30:00.000-05:002013-01-08T16:30:00.422-05:00Fun Things I (Re-) Learned About IE CSSWe're building a customer's web application, which means I've been getting my hands dirty in CSS again. Our front end stack is pretty standard: Sass, 960 Grid System, and Compass. I frequently use bootstrap but here the design just doesn't work with it.<br /><br />Now, I have two confessions to make that are relevant:<br /><br /><ol><li>I'm a mac user.</li><li>The designer we're working with on this one has an aesthetic that I would call "application-oriented corporate clean". (This is a compliment, I swear!)</li></ol><div>The design language calls for gradients in a lot of places for texture, uses rounded corners and button edges, and favors text on whitespace over controls and cluttered layouts. </div><div><br /></div><div>So I went along styling things, and I think it looks pretty good. Here's what it looked like in Safari and Chrome:</div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-FZc2KDyQQjY/UOirHrmX_cI/AAAAAAAAAYQ/vfW63gPMQXA/s1600/Screen+Shot+2013-01-05+at+5.32.36+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="182" src="http://4.bp.blogspot.com/-FZc2KDyQQjY/UOirHrmX_cI/AAAAAAAAAYQ/vfW63gPMQXA/s320/Screen+Shot+2013-01-05+at+5.32.36+PM.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: left;">Not too bad! There's still some polish needed, but it's looking pretty nice.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Then I launched Internet Explorer (this is IE9), and here's what I saw.</div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-vvBDdklSPaw/UOirHyiaU7I/AAAAAAAAAYU/oGuV6iXL-B8/s1600/Screen+Shot+2013-01-05+at+2.43.05+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="196" src="http://4.bp.blogspot.com/-vvBDdklSPaw/UOirHyiaU7I/AAAAAAAAAYU/oGuV6iXL-B8/s320/Screen+Shot+2013-01-05+at+2.43.05+PM.png" width="320" /></a></div><div><br /></div><div>Oooops. Forget polish. That's just ugly. A few hours later, I've got it looking better. There were some fun things I learned (or re-learned) about IE9 CSS along the way. The rest of this post shares the changes I made to get Internet Explorer up to snuff. Note that I've just included the Compass includes where I was using them.</div><div><br /></div><div><b>No Image Borders</b></div><div>The logo had that purple image border. No, I don't know why it does. Let's get rid of it. Just add this to the img tag CSS:</div><div><span style="font-family: Courier New, Courier, monospace;">border: none;</span></div><div><br /></div><div><b>Create Non-Gradient Backgrounds</b></div><div>I warned you - lots of gradients! IE9 doesn't like gradients. See that header? It looked like this:</div><div><div><span style="font-family: Courier New, Courier, monospace;">@include background-image(linear-gradient(#7184a8, #27486b));</span></div></div><div><br /></div><div>I changed it to look like this:</div><div><span style="font-family: Courier New, Courier, monospace;"> background: #536d96;</span></div><div><div><span style="font-family: Courier New, Courier, monospace;">@include background-image(linear-gradient(#7184a8, #27486b));</span></div></div><div><br /></div><div>Notice that the background color is neither the start nor the end stop color from the gradient. It's in between the two. Also notice that I specified the background first.</div><div><br /></div><div><b>IE9 Doesn't Like Text in Button Tags</b></div><div>This showed up with no text at all on the button. The text was in the DOM but it wouldn't display.</div><div><button>Log In</button></div><div><br /></div><div>This worked like a charm:</div><div><input class="button" type="button" value="Log In" /></div><div><br /></div><div><b>jQuery Required for Placeholders</b></div><div>We use placeholder text in a few forms (not shown in the screenshots) for questions that might be confusing. Too bad placeholder is an HTML5 thing that isn't supported on IE9 and earlier. Unfortunately, you have two choices: put the text elsewhere on the page, or use JavaScript to set values. I added the<a href="https://github.com/mathiasbynens/jquery-placeholder" target="_blank"> jQuery placeholder plugin</a> and a little bit of CSS styling, and it magically worked. (whoo hoo!)</div><div><br /></div><div>And we're done! Sure, IE doesn't look quite as polished without the gradients, but it's at least not hugely bad. Just four things take"yikes" to "could use polish". It's amazing how big a difference just a few things can really make.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com1tag:blogger.com,1999:blog-8341729382206275662.post-43577675033205417002013-01-04T14:10:00.000-05:002013-01-04T14:10:17.198-05:00On ResolutionsNew Year's Resolutions are hardly a new phenomenon. They're ubiquitous in our daily lives. Everywhere you turn magazines and TV shows and friends and family are making resolutions and encouraging you to make resolutions: lose weight, exercise more, give up smoking, tidy the house, get organized, be a better friend, laugh more, get that raise, find a new and better job, etc.<br /><br />It gets tempting to make work resolutions, too, either individually as a team. THIS is the year we finally get serious about technical debt. This year we resolve to not let product management impose arbitrary deadlines. This year we're going to pair program at least 25% of the time. Work resolutions are great. They're basically goals, and goals are good things in general. They give you a direction and something to strive for as a team.<br /><br />January is a terrible time for work resolutions.<br /><br />Think about all the things going on during January at work:<br /><br /><ul><li>Those year end projects that didn't quite get finished are now really urgent so they still count toward last year. (No kidding - I have more than one client that counts the end of the quarter as January 15th for bonus and goals purposes.)</li><li>The business is often making annual and quarterly goals</li><li>It's roadmap update time: the 6, 12, and 18 month roadmaps all need a quick refresh</li><li>People are still rolling in from vacations at the end of the prior year</li><li>Finance is doing end of year close outs and bugging everybody for final paperwork and expense reports and whatnot.</li><li>Many teams have new members or offer internal reshuffles around this time.</li></ul><div>All of that activity means that in January you're spending less time doing your day to day job and more time dealing with the activity. This isn't a bad thing, but it's the state of the work world. Adding work resolutions on top of that, though, is a recipe for failure. Sure, we'd love to pair program more, but we've got 4 hours of meetings today, and can't get two people at a keyboard for longer than 30 minutes. Yes, we do need to tackle technical debt, but gosh, we just sat through a presentation of the quarterly business goals and truly I don't know what that means for development.</div><div><br /></div><div>All that conspires to make sure that we're not going to succeed at our new resolutions. There's a lot of change going on. There are more distractions than normal. It's just not a good environment to succeed.</div><div><br /></div><div>So don't try. Don't make work resolutions in January.</div><div><br /></div><div>Make work resolutions in April.</div><div><br /></div><div>By April, we've all achieved a routine. Things are back to normal, and we have a good idea of how busy we're going to be (so just how ambitious was the business back in January?). April is a good time to make resolutions that you'll be able to keep. You'll know how much you'll be able to work together, and how much technical debt you really can tackle among the features you're being asked for. In other words, you'll be in a position to make resolutions you can keep.</div><div><br /></div><div>And making resolutions is good, but keeping resolutions is great.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-14381240292752539712012-11-12T10:58:00.005-05:002012-11-12T10:58:43.922-05:00A Few CSS Pet PeevesI just started a greenfield project, and remembered again that one of the things I love about greenfield projects is that you get a chance to Do It Right(tm). I'm also working with a team, which means we have a few different people helping decide what Do It Right means, exactly. In particular, we've been having discussions through the pull requests about how to handle CSS and markup. In doing so, I found another benefit - it's really making me crystalize some of the things that I kind of knew but hadn't articulated.<br /><br />I wanted to share the CSS tips and bugaboos I've articulated for myself (and my team) over the past few weeks:<br /><br /><ul><li><b>Use a dynamic stylesheet language.</b> I don't care which one - sass, less or something else - but use a stylesheet language. CSS is much easier when you can use variables, mixins, and other things we programmers take for granted elsewhere. Plus, who really likes doing search and replace on hex codes?</li><li><b>No bare text. </b>Don't use text that's not in a container of some sort. It will be affected by any styling changes that affect the body text, which tends to lead to unintended consequences. In addition, bare text is a lot harder to place appropriately on the page. Put it in a span or a div or a p or something - anything!</li><li><b>No br tags.</b> I'm not a fan of <span style="font-family: Courier New, Courier, monospace;"><br /></span> tags. That's mixing layout and content, which I think is a bad idea, even on a static page. If you really want a line break, it's almost certainly because you're changing to a separate type of content - another paragraph, or another item in a list. That means you should make it a paragraph or a list. Oh, and if you really must use the br tag, at least close it!</li><li><b>html_safe is a minor code smell.</b> The project is a Rails project, but other languages have equivalents. Using<span style="font-family: Courier New, Courier, monospace;"> "<strong>Foo</strong>Bar".html_safe</span> is an indication that you're doing something odd. This can open up a security hole if any of the contents are user input. And if you're not using user contents, then you're probably putting html tags inside a single element - again mixing content and layout, which is not a good idea.</li><li><b>Lists are your friend.</b> Not all lists have bullets or numbers. They're really useful for any layout that is sequential, horizontally or vertically. That means navigation menus, sequential results, etc.</li><li><b>Deep is bad.</b> Particularly when you're using a CSS layout (e.g., Bootstrap) and/or a lot of different backgrounds, it gets really easy to nest a lot of divs to achieve a layout. As the application grows it will start to show in the render time of the page. Use as few divs as possible for simple positioning, and see if there's a way to make them shallower where possible.</li></ul><div>A lot of these thoughts tie back to a separation of concerns. Content, layout/markup and styles are three different things and should be handled in three different places. You create a layout in your views, inject content from the controller (using an MVC framework or similar), and style it with your stylesheet language (ultimately CSS). Don't mix them. </div><div><br /></div><div>What are your CSS-related bugaboos?</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-43812295646964519242012-10-31T13:42:00.002-04:002012-10-31T13:42:40.100-04:00How I Do Pull RequestsI've been working with a couple new developers lately and we've been talking about how we actually write, review and check in code. Early on, we all agreed that we would use a shared repository and pull requests. That way we get good peer code reviews, and we can look at each other's work in progress code.<br /><br />Great!<br /><br />One of the developers approached me after that conversation and said, "umm, so how exactly do I do pull requests?" On Github, here's how I do it:<br /><br /><br /># CD into the project<br /><span style="font-family: Courier New, Courier, monospace;">$ cd Documents/project/project_repo/</span><br /><br /># Check what branch I'm on (almost always should be master when I'm starting a new feature)<br /><span style="font-family: Courier New, Courier, monospace;">$ git branch</span><br /><span style="font-family: Courier New, Courier, monospace;">* master</span><br /><br /># Pull to make sure I have the latest<br /><span style="font-family: Courier New, Courier, monospace;">$ git pull</span><br /><span style="font-family: Courier New, Courier, monospace;">Already up-to-date.</span><br /><br /># Make a new branch off master. This will be my feature branch and can be named whatever I want. I prefix all my feature branches with cmp_ so people know who did most of the coding on it.<br /><span style="font-family: Courier New, Courier, monospace;">$ git branch cmp_NEWFEATURE</span><br /><br /># Switch to my new branch<br /><span style="font-family: Courier New, Courier, monospace;">$ git checkout cmp_NEWFEATURE</span><br /><span style="font-family: Courier New, Courier, monospace;">Switched to branch 'cmp_NEWFEATURE'</span><br /><br />#####<br /># DEVELOP.<br /># Commit my changes because they're awesome<br /># Develop more stuff. Make changes, etc.<br /># Commit my changes, because they're awesome.<br /># Pull from master and merge to make sure my stuff still works.<br /># NOW I'm ready to make a pull request.<br />#####<br /><br /># push my branch to origin<br /><span style="font-family: Courier New, Courier, monospace;">$ git push origin cmp_NEWFEATURE</span><br /><br /># Create the pull request<br /># I do this on github. See https://help.github.com/articles/using-pull-requests<br /># Set the base branch to master and the head branch to cmp_NEWFEATURE<br /><br /># Twiddle my thumbs waiting for the pull request to be approved.<br /># When it's approved, huzzah!<br /><br /># If the reviewer said, "go ahead and merge", then the merge is on me to do.<br /><br /># Check out the master branch. This is what I'll be merging into<br /><span style="font-family: Courier New, Courier, monospace;">$ git checkout master</span><br /><br /># Merge from my pull request branch into master. I use --squash so the whole merge is one commit, no matter how many commits it took on the branch to get there.<br /><span style="font-family: Courier New, Courier, monospace;">$ git merge --squash cmp_NEWFEATURE</span><br /><br /># If the merge isn't clean, go ahead and fix and commit.<br /><br /># Push my newly-merged master up to origin. The pull request is done!<br /><span style="font-family: Courier New, Courier, monospace;">$ git push</span><br /><br /># Go into github and close the pull request. I do this in a browser.<br /><br /># Delete the feature branch from origin. Tidiness is awesome.<br /><span style="font-family: Courier New, Courier, monospace;">$ git push origin :<branch></branch></span><br /><br /># Delete my local copy of the feature branch.<br /><span style="font-family: Courier New, Courier, monospace;">$ git branch -D <branch></branch></span><br /><br /><br />More information can be found here: https://help.github.com/articles/using-pull-requests.<br /><br />Happy pulling!<br />Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-36619784944627993412012-10-26T15:17:00.001-04:002012-10-26T15:17:26.346-04:00Use Your Own APIOne of the early milestones for an engineering team is the development of the first API. Someone wants to use our stuff! Maybe it's another team in the company, or another company altogether. Either way, someone will be consuming your API.<br /><br />That's truly awesome news. It's always fun to see the great things teams can accomplish with your work.<br /><br />So how do we create an API? Most of this is fairly straightforward:<br /><br /><ul><li>Figure out what people want to do</li><li>Create an appropriate security model</li><li>Settle on an API model (RESTful JSON API? XML-RPC? Choose your technologies.)</li><li>Define the granularity and the API itself.</li><li>Document it: training materials, PyDoc/rdoc/javadoc, implementation guide, etc.</li></ul><div>The trouble is that most people stop there. There's actually one more step to building a good API:</div><div><br /></div><div><b>Use your own API.</b></div><div><br /></div><div>All the theory in the world doesn't replace building an application with an API. Things that seem like great ideas on paper turn out to be very painful in the real world - like a too-granular API resulting in hundreds of calls, or hidden workflows enforced by convention only. Things that seemed like they were going to be hard are easy. Data elements show up in unexpected places. This is all stuff you figure out not through examination, but through trying it.</div><div><br /></div><div>So try it. Create an API, then create a simple app that uses your API. It's amazing what you'll learn.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-38184038284263155772012-10-19T16:46:00.001-04:002012-10-19T16:46:46.700-04:00Mind Your WordsWhen you're surrounded by other engineers all day, it's easy to forget that some words have other meanings. Take "CRUD", for example. In engineering, that's shorthand for Create Retrieve Update Delete - your standard data operations. In real life, it's a derogatory term.<br /><br />At several of my client sites, we use CRUD as engineers do. "Yeah, I've just implemented the CRUD operations; it's not pretty yet." "That's just a CRUD workflow? Yup!" "CRUD looks good."<br /><br />When you get in front of non-technical folks, though, that exact conversation takes on a whole new tone. All of a sudden, you're a coarse, derogatory engineer. Oops!<br /><br />Long story short, mind your words. Context changes meaning!Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-23972568603858819062012-10-16T14:17:00.002-04:002012-10-16T14:17:54.080-04:00Management by Monopoly MoneyI work with a lot of different teams, and almost all of them have some concept of a backlog. Basically, it's a list in some approximation of priority that the team works from. How they pull off the backlog and how stuff moves around the backlog varies a bit, but that's the basic idea.<br /><br />One of the frustrations with this kind of backlog management is that certain things get short shrift. The person who owns the backlog has - through no fault of their own - certain biases. Often, it's whoever shouts loudest or most recently, or things that relate to that person's background get priority (e.g., an ex-IT guy will prioritize technical debt and deployment/monitoring items, while an ex-sales person will prioritize customer and sales requests). This leads to fun conversations and ideas like, "well, 10% of our stories should be paying down technical debt," or "every fifth story should be a customer request." In theory this works well. In practice, things aren't nearly that smooth. In practice, sometimes things come up and we skip our customer story in favor of a strategic priority, or we don't hit our technical debt goal.<br /><br />There's another way.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-sR2CpS2bQeo/UH2jRh1DB0I/AAAAAAAAAX4/UxjfGKsMkQQ/s1600/monopoly-money.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="215" src="http://3.bp.blogspot.com/-sR2CpS2bQeo/UH2jRh1DB0I/AAAAAAAAAX4/UxjfGKsMkQQ/s320/monopoly-money.jpg" width="320" /></a></div><br />Yup, Monopoly money!<br /><br />It sounds silly, but bear with me. When we make statements like, "10% of our time should be on technical debt", we're talking about a budget. So let's use budgeting tools - money.<br /><br />Here's how it works:<br /><br /><ol><li>The product owner and management work to set a budget. It usually is as simple as agreeing that sales gets 25%, product management gets 50%, engineering gets 25%.</li><li>Set a total budget amount that reflects the total amount of work you expect the team to accomplish.</li><li>The representative from each group gets monopoly money according to their proportion of the budget. Usually it's a dollar a point (or $10 a point, if you're feeling rich).</li><li>As you create the backlog, each group spends their money. When they're out, they're out.</li></ol><div>Try to keep your budget over a fairly short period of time - a few sprints, or no more than a quarter. That way there's a reset opportunity before anything gets too skewed.</div><div><br /></div><div>This turns fun very quickly. By providing money, you're creating an economy. The IT guy will trade away some of his money in exchange for getting it back from marketing next quarter, for example. Or two groups will band together to outspend everyone and push a feature they don't want onto the backlog. It also makes the process very concrete. There's no stretching or remembering. There's just how much money each group has left.</div><div><br /></div><div>Making abstract work concrete and sticking to a budget.... now that's worth a shot. Give it a try.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-47081455669948697572012-10-11T15:20:00.000-04:002012-10-11T15:20:01.662-04:00Installing Umbraco PackagesJust a quick tech note today, for anyone using Umbraco.<br /><br />I was attempting to install a package from the Umbraco package repository and kept getting an error: ERR_NAME_NOT_RESOLVED. It looked like a DNS error, but I couldn't find any DNS problems!<br /><br />I finally found the right answer: it's the world's most poorly formed permissions problem. Give your IIS user read, write and execute permissions on c:\Windows\Temp, and the problem will go away.<br /><br /><br />Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com1tag:blogger.com,1999:blog-8341729382206275662.post-36973910916420319972012-10-09T09:59:00.001-04:002012-10-09T09:59:16.366-04:00The Overloaded TesterAs most of you know, I came up through software testing, before branching out into development and management. I still like to keep in touch with my roots, and spend a lot of time working with my clients on the test function in software.<br /><br />I've noticed a trend recently toward overloading the tester. It's no longer fashionable to simply have testers. That's "old school" "retro" thinking that produces script monkeys and poor manual testers. The bright shiny way now is to have test automation gurus - basically developers who specialize in developing tests and test frameworks - and a customer or customer proxy who helps define what to test.<br /><br />All in all, I don't have a problem with the thinking behind the trend. Yes, script monkeys give testing a bad name. Yes, test automation can be a hugely valuable tool. Yes, listening to the customer is great. Like many trends, it went too far, but it's starting to swing back. And that's where things are getting interesting.<br /><br />You see, we have all these manual testers, and some of them are very good. Some of them know the business and the uses like the backs of their hands, and we're starting to recognize how valuable that knowledge is. Others know the attributes of testable, maintainable, scalable software and can be great testing in the code review or architecture era. What we used to call a manual tester can now be a great future proofer.<br /><br />We're really starting to overload the tester. Now instead of hiring a senior manual tester, we see job reqs for a senior tester that include phrases like:<br /><br /><ul><li>"owns the quality process"</li><li>"evangelist for good software development and delivery practices"</li><li>"works across the organization to instill a culture of quality"</li></ul><div>Your most senior testers are becoming - at least in some places - process gurus and influencers more than testers. They may never actually test a piece of software.</div><div><br /></div><div>This actually isn't inherently a good or a bad thing. Some companies have experimented with similar ideas on the development side for years, often under the title "Office of the CTO". It's a kind of roving expert consultant who works exclusively within one company but works across the organization. Seeing this start to come up in testing.... well, it's a career path for testers who don't want to get into managing people.</div><div><br /></div><div>I think overall I'm for this trend of testers taking on a broader role in the organization. Just be careful you know what you're getting into!</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com1tag:blogger.com,1999:blog-8341729382206275662.post-51325083399376866782012-10-03T11:29:00.000-04:002012-10-03T11:29:03.067-04:00Team NeutralI have a client who has outgrown their scrum team. Daily standups are taking longer and longer, and the team doesn't really fit into their room very well at all. Sprint planning is getting more and more... fun, too. And by fun I mean long.<br /><br />So we're splitting the teams. Going forward, we will have two functionally equivalent teams. First order of business: a team name!<br /><br />Sounds simple, right? Nope, not so much. Let's back up for a second.<br /><br />This isn't the first client I've had who's split teams. The last client that split wound up with three teams needing names. And then the fun started. One team suggested greek alphabet as a theme. They would, of course, be Team Alpha. The second team would be Team Beta. The third team would be Team Omega. Team Beta was particularly unamused. Another team suggested a theme of 80's TV shows. They would be Miami Vice (cool cars!). The second team would be Growing Pains. The third team would be the Golden Girls (this team, incidentally had no women). Neither team was amused. The third team suggested a simple numbering system. They would be team 1. Someone else would be team 2. And the last team would be team 3. The squabbling continued.<br /><br />It took about three weeks to land on colors as a relatively neutral theme. Granted, this was an extreme example of a group that collectively contained some pretty fragile egos and a highly developed sense of hierarchy.<br /><br />The underlying point is interesting, though. It's useful to give teams names. After all, we have to refer to them somehow. It's also fun to let teams pick their own names.<br /><br />But.<br /><br />Make sure those names are neutral and don't imply positioning or relative importance in any way. Neutral things like colors, places, video games, and others are a good idea. And make sure every team gets to pick their own name.<br /><br />One day, I'll get to be on Team Neutral. Until then, you can find me on Team has-a-neutral-name.Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-72798430306182537502012-09-25T13:08:00.001-04:002012-09-25T13:08:27.384-04:00Clean Project ChecklistSome projects are harder than others. On a few of my projects, everything just feels harder than it should be. I can't find the classes I need to change; the tests on a clean checkout fail; configuration is manual and fiddly; getting set up to try your code is slow and unwieldy. They're just painful all around. Other projects are smooth and easy. There's a solid README for setting it up - and the README is short. Tests run well on clean checkout. Classes and methods are in the first place you look. The only hard part of these projects is any difficulty in actually solving the technical problem.<br /><br />The main difference, I've discovered, is in the tooling around the projects. Some of the smooth projects are huge and involve different services and technologies. Some of the difficult projects are actually quite small and simple. When the tooling is clean and works, then the project is much more likely to be smooth. Over time I've come to look for a set of things that tend to indicate a clean project.<br /><br />This is my clean project checklist:<br /><br /><ul><li><b>Deployment and environment setup is automated using an actual automation tool.</b> I don't care if it's Capistrano, Chef, Puppet, RightScale scripts or whatever. It just has to be something beyond a human and/or an SSH script. This includes creating a new box, whether it's a cloud box or a local machine in a data center somewhere. If it's scripted then I don't have to fiddle a lot manually, and it also tends to mean there's good isolation of configuration.</li><li><b>Uses Git.</b> This makes the next item possible. It's also an indicator that the developers are using a toolchain that I happen to enjoy using and to understand.</li><li><b>Developers are branch-happy.</b> Feature branches, "I might mess this up" branches, "just in case" branches - developers who are branch happy tend to think smaller. With that many branches, most don't survive for long! Smaller changes means smaller merging, and that makes me happy. It fits nicely with the way I work. I should note that I don't care how merging happens, either by merge or by pull request.</li><li><b>Has a CI system that runs all the automated tests. </b>It might not run them all in one batch, and it might not run them all before it spits out a build, but it runs them. The key here is that automated tests run regularly on a system that is created cleanly regularly. This cuts down on tests that fail because they weren't updated, or issues that relate to data not getting properly put in the database (or other data stores).</li><li><b>Cares about the red bar. </b>The build shouldn't be broken for long, and failing tests should be diagnosed quickly. In policing, it's called the broken windows problem: if you get used to small bad things then bigger bad things will happen. Don't let your project windows break.</li></ul><br />I'm sure there's more, but what else am I missing?Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com2tag:blogger.com,1999:blog-8341729382206275662.post-88527569350650651022012-09-18T12:00:00.000-04:002012-09-18T12:00:41.143-04:00Automate What?I was in a meeting the other day, talking about an upcoming project. I made some offhand comment about needing to make sure we allowed for a continuous integration and test automation environment when we were sizing our hardware needs. The response was immediate: "but automation never works!" After a bit of discussion, it emerged that this team had never attempted automation at any level under the GUI, and their GUI automation was, well, not good.<br /><br />Automation at the GUI level is a legitimate thing to do. It's far from the only automation you can do. Consider all the other options:<br /><br /><ul><li>Automated deployment. Manual scripts or with tools - this is an entire discipline in itself. And it doesn't have to deploy to production; automated deployment to test or staging environments is also useful.</li><li>Unit tests. Yes, this is test automation, too.</li><li>API tests. Automation of a user interface, jut not a graphical user interface.</li><li>Integration tests. You can test pieces together without testing the whole thing or without using the GUI.</li></ul><br />So here's my automation heuristic:<br /><b>Automate as much as you can as low as possible.</b><br /><br />Let's break that down a bit. "Automate as much as you can" means just that. Not everything is automate-able, and not everything should be automated. If you have a GUI, testing that the colors go nicely together is probably not automate-able - so don't do it. Do that manually. If you have a method that takes inputs and produces outputs, you can probably automate the test that confirms it works with different kinds of inputs and outputs. If automating something involves massive architectural changes or fails one in three times randomly, then you're not going to maintain it and it's either not automate-able or simply broken.<br /><br />(On a somewhat related code, the ability to automate something frequently correlates with how modular and maintainable an architecture it has. Hard-coded configuration parameters, nonexistent interfaces, etc. make code less testable and also a lot harder to maintain!)<br /><br />"As low as possible" means that you should target your automation as close to the code you're trying to affect (deploy or test, for example) as you can. If you're testing that a method does the right thing, use a unit test. Sure, it might be possible to test that same method through a GUI test but the overhead will make it a lot slower and a lot more brittle. The team I was talking with was right about one thing: GUI tests tend to be brittle. If you can go below the GUI - either through an API or using an injected test framework (think xUnit tests) - then you can avoid the brittleness.<br /><br />Yay automation! But even more yay, appropriate automation!Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com5tag:blogger.com,1999:blog-8341729382206275662.post-25577266067796629922012-09-14T07:05:00.000-04:002012-09-14T07:05:00.672-04:00Don't Forget the JoyWork is, well, work. It's also an open secret that we're better workers when we have fun at work. We're <a href="http://www.guardian.co.uk/science/2010/jul/11/happy-workers-are-more-productive" target="_blank">more productive</a>, we <a href="http://pps.sagepub.com/content/5/4/378.abstract" target="_blank">help the bottom line</a>, and we're more likely to stay in a job longer if we enjoy our jobs. So let's roll up our sleeves and get to work, but don't forget the joy!<br /><br />Some joy comes from the work itself. There is a thrill in solving a hard problem. Learning a new technique provides a quiet satisfaction. Finally understanding some concept - really understanding it! - puts a spring in my step. Looking at a demo or a customer report and knowing I built some feature they really love sends me home bragging. I know I'm not alone in quite simply loving what I do.<br /><br />Other joy coms from the culture around the work. This is where your colleagues and your work environment come in. Joking around the coffee machine is just plain fun. Having your desk set up the way you like it - with your Star Wars figurines and footrest - makes the physical office more comfortable. We're people, after all, not automatons.<br /><br />As an employer, there are things I can do to help make work more fun. Most of them aren't even very expensive! Consider these:<br /><br /><ul><li>A training course - online or at a local university's extension school - for an employee who asks usually costs under $1000.</li><li>Letting someone go speak at a conference costs about 20 hours for prep and the cost of plane/hotel. (The conference itself is usually free for speakers.)</li><li>Letting the team choose a theme for sprint names and name their own sprints. Free and often hilarious.</li><li>Bringing in bagels or cookies or cake once or twice a month - either on a schedule or ad hoc, depending on your team's sense of routine - is surprisingly fun. Keeping snacks on hand accomplishes the same thing.</li><li>Don't do management by walking around. Be available and show up but don't hover. You don't want to be your employees' friend, but you don't want to be the heavy, either. Free, too.</li></ul><div>Joy has a place at work. Encourage it.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-10435881897627318572012-09-11T10:25:00.000-04:002012-09-11T10:25:00.187-04:00Status Message MessagingFor those of us who use hosted services, status pages are an essential communication point. They're a way to indicate service health ("it's not us, it's you") and, when there are problems, they provide a forum for disseminating updates quickly and loudly. The "everything is okay" update is pretty easy. The "stuff's broken" update is a much more delicate thing to write. It has to reflect your relationship with your users, but also reflect the gravity of the situation.<br /><br />Here's part of a status update <a href="http://status.beanstalkapp.com/" target="_blank">Beanstalk</a> published this morning:<br /><br /><blockquote class="tr_bq">"Sorry for the continued problems and ruining your morning." </blockquote><br />Oh man. That's an update you don't want to have to publish. To provide some context, we'll just say that Beanstalk has had a bad few days. Beanstalk provides git and subversion hosting; that makes them a high-volume service. Pushing, pulling, committing, checking in/out, etc. happen very frequently and, well, software teams on deadline are not known for being nice when their tools get in the way. The last few days have been hard on Beanstalk: they got hit by the <a href="http://www.tomshardware.com/news/GoDaddy-DDoS-Anonymous-Own3r-Verisign,17484.html" target="_blank">GoDaddy attack</a>, then had a problem with load on their servers traced to an internal problem, and finally are again having difficulties with their file servers that host repos. And you can see it in that status update. "[R]uining your morning" is the phrasing of someone who is seriously exasperated. That update does some things well: it shows they understand the problem is severe; and it reflects the increasing frustration users are likely experiencing. It's escalating, just like user's tempers are probably escalating. However, it goes too far for my taste. It reeks of frustration on the part of whoever wrote the update, and that's clearly not a good head space for actually solving the problem. It also implies a sense of fatalism. That update was at 9:23am - my morning might still be salvaged, if they can get the system back up relatively quickly. Don't give up, guys!<br /><br />There's an art to writing the status update when things are going poorly. When I'm working with a team fixing a major problem, I'll dedicate someone to doing just that. They sit in the middle of the war room (or chat session or conference call) and do nothing but manage status communications. Let the people fixing the problem focus on fixing the problem. Hand off status to someone who will maintain a level head and write a good status update, considering:<br /><br /><ul><li>Frequency of updates. At least every hour for most issues, and whenever something changes there should be a status update. Silence does not inspire confidence.</li><li>Location of updates. As many channels as possible are good. Use twitter, the status page, email or phone calls to really important customers, and any other tools at your disposal.</li><li>Tone of updates. This needs to match your general tone of communication (see the Twitter fail whale - still cute and fun, even in error!) but also show that you know your customers are getting frustrated.</li><li>Inspiring confidence. Providing enough information to look like you are getting a grip on the problem and will get it fixed is important. Providing a proper postmortem also helps inspire confidence.</li></ul><br /><br /><br />Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-7052190706251759122012-08-31T13:47:00.000-04:002012-08-31T13:47:06.970-04:00Consider the MessageA couple days ago I was at the butcher picking up some meat for supper (burgers!). My card got declined. And here's the thinking: "Oh wow embarrassing! I come here all the time! I'm sooo not that person. I'm fiscally responsible, darn it! Besides, I'm nowhere near the limit. How annoying!" It's about a 5 second panic, but let's be honest, it's not a good feeling. It's embarrassing and annoying for both parties - for the cashier and for me.<br /><br />So I paid with cash, and as I was going out, the cashier handed me the receipt from when it got declined. Here it is:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-oU9gxhG3Qrg/UED23y72WPI/AAAAAAAAAXY/4TOmDpSP9n0/s1600/photo.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://1.bp.blogspot.com/-oU9gxhG3Qrg/UED23y72WPI/AAAAAAAAAXY/4TOmDpSP9n0/s640/photo.JPG" width="476" /></a></div><br /><br /><br />Seriously?! Seriously!?!? That 5 second panic and the annoyance for me and for the cashier - and check out that decline reason:<br /><br />"Could not make Ssl c"<br /><br />I'm going to assume that means "Could not make an SSL connection to <something or="or" other="other">". Bonus points for the truncated message and for the interesting capitalization.</something><br /><br />That's why error messages matter. The error shouldn't have been "Declined". It should have been "Error". That would have saved us all the embarrassment, at least! (Yeah, it still would have been annoying.)<br /><br />So please, consider your error messages. They matter.Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-19061060017125405992012-08-29T15:02:00.001-04:002012-08-29T15:02:38.015-04:00Autonomous and Dependent TeamsAlmost all of my clients are currently doing some variation on agile methodologies. Most of them are doing SCRUM or some version of it. And yet, they are very different teams. In particular, lately I've noticed that there are two kinds of teams: those that encourage autonomy and those that encourage dependence.<br /><br />To be clear, I'm speaking entirely within the development team itself. Within a development team there are invariably leaders, usually the ones who have been around for a while and show the most ability to interact on a technical level with the rest of the team. The character of those leaders and how much autonomy non-leader team members have says a lot about the team.<br /><br />Teams that encourage autonomy take the attitude that team members should help themselves. If a member of the team needs something - a new git branch, a test class, a method on an object in another area of the code - then that person is responsible for getting it. How the team member accomplishes that is, in descending order of preference: (1) doing it; (2) asking for help to do it with someone (pairing and learning); (3) asking someone else to do it; (4) throwing up a request to the team at large.<br /><br />Teams that encourage dependence have a very different attitude. These are teams where each person has a specialty and anything outside that specialty should be done by a leader. If a team member needs something - a new git branch, a test class, a method in another layer of the code - then that person should ask a team leader, who will provide it. Sometimes the leader passes the request off to another team member, and sometimes the leader simply does it.<br /><br />Let's look a little deeper at what happens with these teams.<br /><br />Autonomous Teams<br /><br /><ul><li>Emphasize a leaderless culture. These are the teams that will say, "we're all equals" or "there's no leader." There are people who know more about a given area or technology, but the team considers them question answerers more than doers in that particular area.</li><li>Can better withstand the loss of one person. Whether it's vacation, maternity leave, or leaving the company, the absent person is less likely to have specialized knowledge no one else on the team has. It's a loss that's easier to recover from.</li><li>Tend to have more tooling. Because there's no dedicated "tools person", everyone introduces tooling as it's needed, from a continuous integration system to deployment scripts to test infrastructure to design diagramming. Over time this actually winds up with more tools in active use than a team with a dedicated tools engineer.</li><li>Produce more well-rounded engineers. "I don't do CSS" is not an excuse on this team. If the thing you're working on needs it, well, you do CSS now!</li><li>Work together more. Because each team member touches a larger area of the code base, there's more to learn and team members wind up working together frequently, either as a training exercise, or to avoid bumping into each other's features, or just because they enjoy it.</li><li>Tend toward spaghetti code. With everyone touching many parts of the code, there is some duplication. Coding standards, a strong refactoring policy and static code analysis can help keep this under control.</li><li>Have less idea of the current status. Because each team member is off doing, they don't always know the overall status of a project. This is what the daily standup and burndown charts are supposed to help, and can if they're done carefully.</li></ul><div>Dependent Teams</div><div><ul><li>Have a command and control culture. These are the teams that say, "we'd be dead without so-and-so" or "Blah tells me what to do." They look to the leader (or leaders) and do what that person says, frequently waiting for his opinion.</li><li>Can quickly replace non-leaders but have a huge dependence on leaders. When a leader is missing - vacation, meeting, or leaves the company - then the team gets very little done, and uses the phrase, "I don't know. So-and-so would normally tell me, but he's not around."</li><li>Have a good sense of overall status. The leaders tend to know exactly where things stand. Individual team members often do not.</li><li>Do standup as an "update the manager" period. The leader usually leads standup, and members will speak directly to that person (watch the body language - they usually face the person). Standup often takes place in shorthand, and not all team members could describe each task being worked on.</li><li>Tend to work alone or with a leader. Because individual team members tend not to work on similar things or to know what everyone is doing, they'll often work alone or with a team leader.</li><li>Tend to wait. You'll hear phrases like, "well, I need a Git branch; has one been created yet?" Instead of attempting to solve the problem - for example, by looking for a branch and creating one - the team member will note the problem and wait for a leader to fix it or to direct the fix. </li></ul></div><br /><br />Overall, I vastly prefer working with teams that encourage autonomy. There are moments of chaos, and times when you find yourself doing some rework, but overall the teams get a lot more done and they produce better engineers. I understand the appeal of dependent teams to those who want to be essential (they'd like to be the leaders) or to those who just want to do what they're told and go home, but it's not for me. Viva the autonomous team!<br /><br /><br /><br /><br /><br /><br /><br /><br />Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-5066720631644653092012-08-24T11:27:00.003-04:002012-08-24T11:27:49.751-04:00"Who Was That Masked Man?"When we were kids, we'd occasionally get to watch the Lone Ranger. We watched the fifties version, with the Lone Ranger and Tonto riding into town in black and white and saving the day. Inevitably, it would end with someone staring into the camera and asking, "Who was that masked man?" as the Lone Ranger rode off to his next town.<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://4.bp.blogspot.com/-VsaLHRDyQ68/UDeVnPOp46I/AAAAAAAAAXE/4phTnAQPllM/s1600/06_1949_Lone_Ranger_TV.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://4.bp.blogspot.com/-VsaLHRDyQ68/UDeVnPOp46I/AAAAAAAAAXE/4phTnAQPllM/s320/06_1949_Lone_Ranger_TV.jpg" width="255" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">"Here I come to save the day!" (Wrong TV show, right sentiment)</td></tr></tbody></table><br />I watched the show again not too long ago with a friend's son, and got to thinking that there really was something to this idea of someone riding into town, clearing out the bad guys, and riding off into the distance. It's really rather like being a consultant in some ways. You ride in, find the bad parts, fix them, and ride out. Fortunately for me, there is a lot less horseback riding and gunplay in software than there ever was in the Lone Ranger!<br /><br />But let's look at each of those steps:<br /><br /><ol><li>You come in</li><li>You find the bad part(s)</li><li>You fix them</li><li>You leave</li></ol><div>All of those steps are important. If you leave without finishing every single step, well, you're no Lone Ranger.</div><div><br /></div><div><b>Come In</b></div><div>Coming in doesn't have to mean going to the client's offices. It just means that you need to show up. You have to interact with the client - and not just the project sponsor. This is how you'll know the full extent of the problem, and start to build trust to fix it. This means you have to be around and be available for casual conversations. This might be in person, by phone, in chat rooms, or over IM.</div><div><br /></div><div><b>Find the Bad Part(s)</b></div><div>You're here because there's a problem the client can't or won't solve internally. Understanding that problem gives you the bounds of your engagement. Sure, there are probably other things you could optimize or improve, but don't lose sight of the thing you're actually here to fix!</div><div><br /></div><div><b>Fix Them</b></div><div>You have to actually fix the bad part(s). Don't offer a proposal; don't outline the problem and note how it could be fixed. Do the work and fix it. This is what differentiates the Lone Ranger from the stereotypical management consultant.</div><div><br /></div><div><b>Leave</b></div><div>This part is surprisingly hard sometimes. Sometimes the problem will be fixed and you just keep coming around, or start working on a new problem, or maintaining the fixes. This is all well and good until you're sure the fix is stable, or if there is another problem to be solved. When it's just maintenance, though, then it's time to leave. Don't forget to actually do that part.</div><div><br /></div><div>And that is how 24 minutes with the Lone Ranger turned into a rant on consulting software engineers. Now, back to the fake Wild West for me!</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-12180200349403917882012-08-20T12:34:00.000-04:002012-08-20T12:34:00.624-04:00The Dreaded Feature ListWe've all seen them: the lists of features. Whether they show up in a backlog, or a test plan, or a competitive matrix, or an RFP, feature lists are everywhere. It's the driving force of software development, in many ways. "How many features have you built?" "When will that feature be ready?" "Does it have X feature?"<br /><br />There's one big problem with that feature focus, though: it's not what customers actually want.<br /><br />There are only two times I can think of where a customer actually explicitly cares about features:<br /><br /><ol><li>When comparing different products (RFP, evaluation, etc)</li><li>When they're using the presence or absence of a feature as a proof point in an argument about your product</li></ol><div>The rest of the time, they care only that they can solve their problem with your product. Having a "print current inventory" feature is useless. Being able to take a hard copy of the inventory report to the warehouse and scribble all over it while doing a count - that's what the customer actually wants. "Print current inventory" is just a way to get to the actual desire. These stories - tales of things the customer does that involve your software - are the heart and soul of the solution.</div><div><br /></div><div>So - with the exception of RFPs and bakeoffs - ignore features. Start focusing on the customer and their stories.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-43799387724218272142012-08-16T11:17:00.000-04:002012-08-16T11:17:00.216-04:00Good Software Makes DecisionsA lot of software is complex. Sometimes it's not even the software that's complex; it's the landscape of the problem that the software is solving. There are data elements and workflows and variations and options. Requirements frequently start with, "Normally, we foo the bar in the bat, with baz. On alternate Tuesdays in the summer, though, we pluto the mars in the saturn. Our biggest customer does something a little different with that bit, so we'll need an option to jupiter the mars in the saturn, too." Add in a product manager who answers every question with, "well, let's make that an option", and you end up with a user interface that looks like this:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-YaT5auZfCaA/UCvC2ebNVkI/AAAAAAAAAWw/e5GyE0z-L8U/s1600/windowslivewriterlightningiiiprosistelpst61drecovery-ee28image-4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://2.bp.blogspot.com/-YaT5auZfCaA/UCvC2ebNVkI/AAAAAAAAAWw/e5GyE0z-L8U/s320/windowslivewriterlightningiiiprosistelpst61drecovery-ee28image-4.png" width="301" /></a></div><br />No one wants to use that.<br /><br />It's software that has taken all of the complexity of the problem space and barfed it out onto the user. That's not what they wanted. I promise. Even if it's what they asked for, it's not what they wanted.<br /><br />Building software is about making decisions. Good software limits options; it doesn't add them. You start with a massive problem space: "Software can do anything!" and limit from there. First, you decide that you're going to solve an accounting problem. Then you decide what kind of inputs and outputs go into this accounting problem, and how the workflows go. You do this by consulting with people who know the problem space really well. Define what you will do and - just as important - what you won't do. Exposing a decision says, "I don't understand this problem; you decide." Making a decision builds customer confidence; it says, "I know what I'm doing." All the time you're creating power by limiting choices.<br /><br />It's okay to make decisions in software. Take a stand; your software will be better for it.Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-71733935631541876722012-08-14T11:44:00.000-04:002012-08-14T11:44:10.870-04:00Don't Claim It If You Only Read ItI've been hiring on behalf of a client lately, looking for a head of QA. One of the trends I noticed as I was reviewing resumes was that a lot of candidates had a list of languages on their resumes: C++, Perl, Ruby, Java, etc. "How cool!", I thought. It's great to see the testing profession attracting people who are capable of writing code but for whatever reason find testing a better fit, Maybe that profession is finally overcoming the stigma of "not good enough for dev" and "tester == manual tester".<br /><br />And then I started the phone screens.<br /><br />I've screened 12 people so far who listed languages on their resumes, and so far not one of them has actually been capable of writing code. Nope, that language list? That's the languages they can <i>read</i>. As in, "I can follow along on code written in C++ or Java."<br /><br />Ouch. Now I'm disappointed in all of them. Here I thought they had some skills they don't have.<br /><br />I understand what the candidates were going for. They're "technical testers" rather than testers who work purely on the business level and don't understand how software works. I get it. I really do. That such a distinction has meaning is sad but true.<br /><br />But don't claim languages if you mean you can read them! You're an engineer, darnit! Claim a language if you can write it. There are enough engineers - and enough testers - who can write code that to claim a language without qualifying it means people will think you write it.<br /><br />If you're trying to say, "hey, I'm a technical tester", then please do so in your resume. Just do so without unintentionally telling people that you're more technical than you are. The right way to say, "I can read but not write C++" is to say: "Languages: C++ (reading), Perl (read/scripting)" or something similar. That way hiring managers don't start with higher expectations than you can meet... And that's good for candidates, too.Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com2tag:blogger.com,1999:blog-8341729382206275662.post-42991536882615386682012-08-07T19:30:00.000-04:002012-08-07T19:30:31.863-04:00The Why Behind He Said SoIn software, we ask "why" a lot. "Why" is a seeking question. If we understand the cause or the reason for something then we can make an intelligent decision about changing it or going around it (and let's be honest - we usually ask why because we want to change it or work around it).<br /><br />The answers to "why" are many and varied, but possibly the worst answer possible is: "Because so-and-so said so."<br /><br />That's not a reason, that's an excuse. Presumably, whoever said so had a reason for saying so, and that's the actual why. There are two reasons we get into this situation:<br /><br /><ul><li>Because that person is almost always right (or in a position of authority that effectively makes them correct)</li><li>Because that person is a convenient target for blame</li></ul><div>It doesn't have to be this way. "Because so-and-so said so" is a learning opportunity. It's a chance to understand better, both this specific scenario and how so-and-so got to be such an expert. Think of it as a chance to check your work.</div><div><br /></div><div>"Why is there a limit of 255 virtual machines on this box?"</div><div>"Because John said so."</div><div><br /></div><div>Well, John's a really smart guy, and he knows the product really really well, so presumably he has a reason for saying so. So why did he say so? "Because we use a /24 network, which allows 256 hosts, and we reserve one address for the physical box." See? Now you actually know something more about the product than you did before. You also know that there's potentially a problem there (networks typically allow 254 hosts, with .0 and .255 generally reserved). </div><div><br /></div><div>Find out why someone said so.... it's illuminating.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-64838206255334892732012-07-30T12:05:00.001-04:002012-07-30T12:05:18.656-04:00Take Pleasure in AbsenceWe spend our professional lives seeking things. We want confirmation of bugs. We want new features. We want affirmation that our bug fixes work. We spend all day every day <i>doing</i> things.<br /><br />Sometimes, though, there is pleasure in not doing things. There is pleasure in absence, and only when we stop doing can we start seeing.<br /><br />Give yourself five minutes while you're making coffee tomorrow morning, put down the iPhone (Twitter can wait!), and consider:<br /><br /><ul><li>The worry no longer felt</li><li>The fear not realized</li><li>The pain not seen</li></ul><div>All that absence! All that not seeking! Feels good, doesn't it?</div><div><br /></div><div>I'm not going to tell you to stop seeking; after all all that absence came from seeking improvements. Instead, take one small breath and notice the beauty of the absence.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-91605922320916747492012-07-24T10:43:00.001-04:002012-07-24T10:43:13.831-04:00You Do What Again?This weekend my aunt, uncle, and about-to-go-to-college cousin were in town visiting. We were catching up, and one of the things my cousin said was, "So what do you do all day?"<br /><br />As background, you should know that both my aunt and uncle are physicians. They don't know what software engineers do all day, either! (Granted, I don't know what physicians do all day, so we're even.)<br /><br />So what do I do all day? In any given day, I'm probably going to do most of this:<br /><br /><ul><li>Modify some existing code</li><li>Send a bunch of emails</li><li>Write some CSS</li><li>Test a feature someone else wrote</li><li>Respond to a customer request or problem</li><li>Attend stand ups and/or scrum meetings</li></ul><div>That really doesn't sound very interesting. Those are the tasks I do, yes, and there is joy in many of them. I actually really enjoy writing code - it's a game to make the software do what I want. I also like playing with someone else's feature and seeing how they interpreted it. There's value, too. Because I write an email, a customer knows what to do. Because I wrote some CSS, a page looks as good as a designer could make it. Because I fixed a problem, a client saved time. That's pretty cool.</div><div><br /></div><div>Those aren't tasks, though. They're accomplishments.</div><div><br /></div><div>So what do I accomplish in a day?</div><div><ul><li>Help others see possibilities</li><li>Make a system do something useful that it didn't do before</li><li>Make a web page more beautiful</li><li>Save time for customers</li><li>Offer my customers abilities they didn't have before</li></ul><div>That's better. That's what I really do.</div></div><div><br /></div><div>What do you do?</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0tag:blogger.com,1999:blog-8341729382206275662.post-56895338033886548852012-07-20T09:41:00.000-04:002012-07-20T09:41:00.648-04:00Synonyms for "Will Work All The Time"The pendulum swings again. Remember work-life balance? Sooooo four years ago.<br /><br />Now we <a href="http://www.forbes.com/sites/ericaswallow/2012/07/19/honey-badger-hiring-ariel-seidman-gigwalk/" target="_blank">hire honey badgers</a>, apparently. We also hire people who want to have a beer at 6pm... as long as they're doing it at work. Hello, brogrammers. Oh yeah, and we'll take a ninja and a rockstar, please! As this guy put it:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-xVkYkhpnV6Q/UAlaDu_RPlI/AAAAAAAAAWI/Kr_-ABoRAsw/s1600/Screen+Shot+2012-07-20+at+9.15.14+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-xVkYkhpnV6Q/UAlaDu_RPlI/AAAAAAAAAWI/Kr_-ABoRAsw/s1600/Screen+Shot+2012-07-20+at+9.15.14+AM.png" /></a></div><br /><br />In other words, we want people who are going to work very long hours and still be good at what they do. Oh, and we want them to be fun. The drinking is really only incentive to stay at work.<br /><br />And that's fine. If you have an all-consuming dream, it's easy to expect others to want to believe in your dream just as much as you do, and to work tirelessly just like you are. That's the kind of thinking that brought us Facebook. Also the Internet. (Okay, so it's not all bad.)<br /><br />Unfortunately, not every effort is the Internet. Some efforts are the next big toy. Or some niche thing. Or - let's face it - something that won't change the world. Some efforts fail. Some are just a bad idea, even if they are a dream.<br /><br />And here's the thing. It's trendy to want people that will work all hours and do it well. The number of people willing to do that for anything is limited. The number of people willing to do that for any dream that is not their own is even more limited. The number of people willing to do that for your particular dream is even smaller. You've severely limited your hiring pool, and we haven't even started talking about things like talent or skills!<br /><br />So be careful before you decide you're only going to hire rockstar ninja brogrammers. Be willing to consider something talented, even if they only want to work 40-60 hours a week. That's 40-60 hours a week more than you're getting from having nobody working for you.<br /><br />Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com3tag:blogger.com,1999:blog-8341729382206275662.post-56664702542903592672012-07-10T09:49:00.004-04:002012-07-10T09:49:58.509-04:00Baby SysadminHerein, a rant.<br /><br />If you're a software engineer of any form - developer, tester, support engineer, or any variation thereon - you should know your tools. That's pretty basic. Java engineers probably ought to be able to compile something, and to know what a library is, and how to set up a class. It's reasonable to expect that Rails testers can describe the difference between factories and fixtures, and when each is useful. We spend time training support engineers in our tools and procedures specifically so they'll know how to use available tools effectively. Pretty basic, right?<br /><br />But software does not live alone. It's been decades since the software we wrote was the only thing involved with running our program. Our software runs in an environment, complete with operating system, other programs, drivers, hardware, third-party dependencies, etc.<br /><br />Shouldn't we know our environment?<br /><br />Some of the problems we solve in our software are related to the environment. We have to handle the case in which our logging can't write because the disk is full. Or we have to test for what happens when our software and some other piece of software both try to use the webcam simultaneously. Or we discover that the hang in our software is actually the user's browser crashing for some unrelated reason.<br /><br />Just like we use tools to create software, we use the environment to create software. We use disk space, or the webcam (and its drivers), or the browser (another piece of software). So just like we need to learn our tools, we need to learn our environment. We need to make ourselves into baby sysadmins.<br /><br />We don't need to know how to do every sysadmin task, but there are some basic things that we should know:<br /><br /><ul><li>How to view what processes are running and basic information (status, memory and CPU utilization)</li><li>Where to look for indications of hardware problems</li><li>How to view network information and utilization</li><li>How the operating system handles disk usage and I/0</li><li>Where the operating system or virtual machine (e.g., JVM) logs and how</li><li>What environment variables are required and how they might be set - both by our software and by external software</li><li>What limits are implied by libraries (e.g., 32-bit versus 64-bit software)</li><li>Roughly how the operating system works, including dependency management</li><li>Roughly how any containers - JVMs or browsers - work, including loading order and frequency, and other dependency management</li></ul><div>None of these things are particularly difficult, and they're all directly related to how your software behaves in its environment. So go ahead, embrace your inner baby sysadmin.</div>Catherine Powellhttp://www.blogger.com/profile/15459370385548771048noreply@blogger.com0