Last week I gave a talk at work on getting the most out of attending software development conferences.
I've been attending conferences for quite a while now and figured I had enough tips in the bag to share with others. Things such as the importance of getting out of your comfort zone, how to learn from other attendees, various note taking tips, and why it is important to review what you learned. The slides from my talk can be seen below:
Blog about software development, agile practices, software use, and the latest happenings in the wide world of technology
Showing posts with label conference. Show all posts
Showing posts with label conference. Show all posts
Tuesday, February 27, 2018
Friday, January 29, 2016
Interview for QA or the Highway
I will be taking my Web Services Testing talk to the QA or the Highway conference next month. I am excited to speak at this QA focused conference for the first time. I have heard a lot of good things about the conference. Alliance Data, my new employer will be sending their entire testing team to the conference, so hopefully I'll have some friendly faces in the audience during my session :) To promote the event and generate buzz, the Testing Curator is interviewing some of the speakers in what they call the Speaker Series. I was recently interviewed. Below is a link to the results.
Saturday, January 9, 2016
CodeMash 2016 - Program some health into your life
Another awesome CodeMash is coming to an end, with a lot of great sessions and a bunch of fun activities throughout the conference. I attended the full 4 days and was joined by my family for the last 2. For the first time my kids attended KidzMash, where they had a great time learning game development, how robots work, building an Altoid-flashlight and learning how to count to F! In the CodeMash spirit I attended mostly sessions outside my immediate comfort zone; including pre-compiler on 7 languages, front-end talks, UX-talks, softskill-talks and a few pertaining to what I am currently working on; microservices and modularity.
I was honored to be presenting at CodeMash for the third time. This time on a non-technical subject dear to my heart. My talk was titled Program some health into your life; where I walked developers through what it takes to stay healthy at a desk job, the basics of nutrition and exercising, and offered various tips on loosing weight and getting the most out of your effort. It went very well and I was not even booed when I suggested bacon was not the cornerstone of a healthy meal plan! :) Apparently there was a free candy buffet going on at the same time I gave my talk, so I was pleased to see a room full of programmers giving up sweets for health advice :) Below are the slides from my talk.
As in years past, hats off to the CodeMash organizers for putting on a great conference. I am already looking forward to CodeMash 2017! Now off to the water park with the family!

As in years past, hats off to the CodeMash organizers for putting on a great conference. I am already looking forward to CodeMash 2017! Now off to the water park with the family!
Tuesday, June 30, 2015
StirTrek Talk Available on YouTube
Last month I had the pleasure of presenting at StirTrek 2015, Ultron Edition. This one day software development conference has grown into one of the premier technology events in town, so I felt honored to get a chance to present. The conference was held at the Rave Theaters in Columbus, and as in previous years the 1500 attendee tickets were sold out in minutes.
I gave a talk on Testing Web Services, similar to ones previously presented at CodeMash and Columbus Code Camp. According to the proctor manning my theater, 217 people attended the session. The presentation went very well and I had a lot of people come up to me afterwards and thank me for the talk, which made me feel good. The talk was recorded and can now be viewed on YouTube. Only the audio and video feeds to the projector were captured, so you wont be able to see my face. Well, maybe just as well. If you want to learn more about SoapUI, JMeter and REST-assured, then give the video a shot. It is about an hour long.
The slides from the talk (with screenshots of most of what I walked through), along with all code/scripts are available in the StirTrek Github repo (downloadable zip file).
I gave a talk on Testing Web Services, similar to ones previously presented at CodeMash and Columbus Code Camp. According to the proctor manning my theater, 217 people attended the session. The presentation went very well and I had a lot of people come up to me afterwards and thank me for the talk, which made me feel good. The talk was recorded and can now be viewed on YouTube. Only the audio and video feeds to the projector were captured, so you wont be able to see my face. Well, maybe just as well. If you want to learn more about SoapUI, JMeter and REST-assured, then give the video a shot. It is about an hour long.
As always the conference ended with a private movie screening. This time the movie was The Avengers: Age of Ultron. My wife joined me and the rest of the Quick Solutions gang for the viewing, which was a great ending to a fun conference.
Friday, January 10, 2014
CodeMash 2014

This year I was fortunate enough to not only deliver one, but two talks at the conference. On Thursday I gave a talk on Web Service testing and Friday I did one on Kanban. The first talk went sort of ok. I was very nervous, felt I stuttered too much through the material and didn't feel very sharp in my thoughts, so I didn't feel super good afterwards. I had a talk with Leon Gersing in the evening and he gave me some great pointers on delivering presentations and dealing with nerves. I went ahead and rehearsed my second talk several times in the evening and then delivered it the following morning and felt way more relaxed, sharp in my thoughts and quite enjoyed giving the talk. So thanks, Leon, for the tips! Now I am waiting for my family to join me at Kalahari, so we can hit the waterpark tonight and tomorrow.
The slide decks from my talks are available on Slideshare:
and
The slides have also been uploaded to the conference GitHub.
Tuesday, January 17, 2012
Ský Development Conference (Links in Icelandic)
Last week I had the pleasure of presenting at the annual Ský Development Conference (Hugbúnaðarrástefna Ský) in Reykjavík, Iceland. This year's conference theme was "The Work Environment of Software Developers". The conference offered presentations on the following topics: Programming Languages, Quality Assurance, Issue Tracking, User Interfaces, Project Management, Databases and Data Warehousing. My presentation was under the Project Management topic, titled "Practical Tips for Software Development Leads". In it I tried to provide some practical tips to team leads and software development managers. Suggestions on such things as how to get the most out of your team, how to manage your time, how to use programming to help with your managerial duties, how to achieve continuous improvement and how to motivate developers. The conference was all in Icleandic, so unfortunately so are the slides. They are available on the conference web site and on Slideshare (mine).
I especially liked Ólafur Gauti Guðmundsson's presentation on the Play framework, which I have been playing with a bit and Stefán Baxter's presentation on NoSQL databases. Margrét Dóra also had a great talk on user interfaces, reminding us that "stupid users" are really our own fault, a result of poor user interface design. And Birna Íris Jónsdóttir had a good QA talk titled "It works on my machine!" where she took some shots at us programmers for all the lame excuses we provide when our stuff breaks! :) All in all a fun day and an enjoyable conference.
Thursday, June 30, 2011
Kanban with David Anderson
Few points from the class:
The Kanban Method is based on three core principles:
- Start with what you do now
- Agree to pursue incremental evolutionary change
- Initially, respect current processes, roles, responsibilities & job titles
The five keys to a successful Kanban implementation are:
- Visualize Workflow
- Limit Work-in-Progress
- Manage Flow
- Make Process Policies Explicit
- Improve Collaboratively (using models & scientific method)
Key class takeaways according to Dave were:
- Kanban is like water
- It goes around obstacles and slowly changes them, rather than removing them like a bulldozer
- Change has to come from within
- How many experts does it take to change an organization? Answer: One. But people are going to have to want to change
Surprising fact from the class:
According to a research done by David, getting more done only ranks number 4 on most manager's lists! The list of their preference being:
- Predictability
- Business Agility (ability to respond to changes in market)
- Good Governments (managing budgets, money spent the way intended, etc.)
- Getting more done
Playing the Kanban game |
All in all a good class and I look forward to continuing the improvement of Kanban at Hugsmiðjan where we develop the Eplica CMS.
Labels:
agile,
conference,
development methodologies,
kanban
Wednesday, February 16, 2011
Jfokus Conference

- Lambdaj - This library is just brilliant and really simplifies working with Collections. Write more readable code in fewer lines. Stop writing loops! Mario Fusco's slides.
- CKJM - Use this library to intelligently pick areas of your code base to refactor. To get bang for your buck you want to pick classes with high Cyclomatic Complexity and high Afferent Coupling. That is, complex code in frequent use. Comes as part of a Sonar plugin. And BTW, if you are not already using Sonar, use it!
- Groovy - I have been intrigued by this language for some time now but never actually put it to use in my work. I think it is time to change that. Groovy to me is a natural progression of the Java language. Making the boring/tedious parts of Java optional and adding syntax improvements and useful features like closures. The kind of changes you might envision seeing in Java 10 or somewhere way down the road. Why wait so long?
As a starting point I am thinking about using these Groovy frameworks for our web based testing: - Geb - Browser automation framework based on Selenium.
- HTTP Builder - A convenient API for complex HTTP requests.
- WADL & Jersey - When consuming/publishing RESTful web services from/to our customers I prefer to have a contract to work by. WADL is just that and Jersey an API (JAX-RS 1.1 implementation) for creating/consuming REST services.
- JDK 7 - Obviously eagerly awaiting that one. Planned GA date July 28, 2011, according to Tomas Nilsson at Oracle.
Other technologies I found interesting but don't envision using in the near future (just not a good fit for Eplica CMS): Scala, Clojure, deploying to the cloud, NoSQL, Vaadin and DDD.
All in all a great conference which I highly recommend to Java developers.
Wednesday, November 17, 2010
Notes on Test Driven Development and Testing
This week I attended the Agilis 2010 conference, including a 2 day course on Test Driven Development by Nat Pryce. Below are a few notes from his class. Not necessarily the key teachings, but rather nuggets of information that I found interesting.
- One of the main arguments for using TDD is that it encourages you to improve the design of your code. Writing the test for a software component that you have designed, but have yet to implement gets you to think about and question the purpose and nature of your design. E.g., if when writing a unit test for a given class you discover that the test code gets way to complex or convoluted, then that is probably an indication that the class being tested has too broad responsibility and should be refactored into smaller, simpler units. I had always thought of TDD as more of a means to ensure you build a comprehensive test suite and as a result have fewer bugs in your software, but had not given much thought to the fact that it is in essence a way to get you to improve your software design; hence making your code easier to understand, use, and maintain.
- We did some exercises using the JMock framework, that Nat Pryce co-wrote. JMock is a neat tool to help you mock out interfaces that your code interacts with and to validate that your code is using the interfaces as expected. JMock allows you to command the mock object of the interface to behave a certain way (e.g. return specific results) and set up expectations for how you are planning to call the interface (e.g. methodA will be called once and only once with arguments "ABC" and 99). These expectations are integrated with JUnit and if not fulfilled by the end of your test run then JUnit will fail the test.
- The following JMock Cheet Sheet page provides an overview of he JMock syntax.
- During the Q&A session with Nat he admitted that JMock was probably best suited for green-field projects (new systems) while frameworks like Mockito where better suited for brown-field projects (preexisting systems that you are trying to create tests for).
- We spent some time discussing Monitoring Events, which is the concept of having your system broadcast notifications (events) about your code execution. E.g. when an order is placed or when a user logs into your system a notification of the event is sent to a JMS Topic that interested parties can subscribe to.
- This is great for logging. A logger component can subscribe to the topic and log all events in the system. It can then allow you to filter out certain events or do things like group events by requestid and provide a holistic overview of a single user transaction (as opposed to having to grep through numerous log files on multiple servers to try piece together what happened when a given user transaction ran through the system, which may have spawned multiple threads in multiple JVMs).
- Monitoring Events are great for testing too. Imagine trying to assert that a call to a checkout service (to complete the purchase of a product) will result in a proper inventory reduction in asynchronous inventory system. If your test runs straight through and checks the inventory status as soon as it has completed the purchase, then the test will likely fail, since the inventory system hasn't had time to process its update inventory request. One might try to fix such a test by adding a sleep statement of say 10 seconds after the checkout call but before the inventory is checked (which still might fail if the system is running slow). Or (which is a little better) one might implement a loop that every 1 second pulls the inventory system to see if the update has been received (succeed fast). In both cases we are polluting our tests with sleep statements and lengthening the time to feedback, when we run a suite of tests. A better way would be to have the test subscribe to the Monitoring Event (topic) and complete (succeed) as soon as it has received an inventory update notification.
- You can also use Monitoring Events to build a support tool for your system. E.g. the tool could send an email or SMS text message to a support person when a certain event is received (OutOfMemoryError, External service not responding, etc) or a when certain number of events have been received over a given time frame.
- Miscellaneous tips on testing and coding
- If you are ever testing code that depends on the system clock (e.g. at noon every day the system is supposed to execute some function) then a neat trick to make that code more testable is to refactor out the dependency on the system clock. E.g. instead of your class making a direct call to say System.currentTimeInMillis(), have your constructor take in a generic Clock object (or define a class variable and use dependency injection to inject a Clock implementation). Then you can have a SystemClock implementation that simply uses the current system clock, where as during your test run, the class under test is initialized with a FakeClock implementation that hardcodes the time to 12 PM)
- In your system tests, which load up and work with data in a database, have your JUnit setUp method clear out the database, rather than the tearDown method. This way you have actual data to look at if a test fails (rather than a clean swiped database).
- Use Simplicators to simplify communication with 3rd party APIs. That is, a facade that maps the 3rd party interface and artifacts over to your domain model or something that makes sense in your system. This way you can more easily test your own code (by using mock Simplicators that don't have a dependency on a 3rd party system) and likewise your code is more easily maintained (e.g. a type change or renaming of a field in some 3rd party XML response may require you to update your Simplicator implementation, but might have no impact on your business code if the response has already been mapped over to your domain model.
- Have separate tests that test your production setup. Basically tests that you can run in production to verify a deployment. Don't deploy your unit/system tests into production. Avoid the painful lesson that GitHub recently experienced where a test run in production cleared out their entire production database!
- When programming, don't have your methods return null! Null checks pollute you code and make it harder to debug. Return empty objects instead.
Saturday, January 10, 2009
CodeMash 2009

![]() | ![]() |
Below is a sprint through the sessions I attended this year.
Day 0 - PreCompiler
Groovy and Grails 101 w. Chris Judd and Jim Shingler
This was a good overview session on Groovy and Grails. Groovy in the morning, Grails in the afternoon. Chris did a good job of explaining all the things that suck about Java, by showing a Java class and then piece by piece groovy-tizing it down to less than half of its original size. The last lab of the morning involved writing code to read an RSS feed and write the ids and title of all blog postings to a relational database, then pull it back from the db and spit out as an XML document. We did this in about 40 min, and I have to say that even with all my Java experience I doubt that I would have been able to pull the same off with Java in that amount of time. Reading from an http url, extracting info from an XML document, writing to a database, reading from a database and creating an XML document was all very easy in Groovy and required very few lines of code. Here is the code that did it:
import groovy.sql.Sql
//Read the RSS feed
def feed = new URL("http://stanjonsson.blogspot.com/feeds/posts/default").text
//Create a database instance
def sql = Sql.newInstance(/jdbc:derby:C:\temp\blogs;create=true/, "APP",
"APP", "org.apache.derby.jdbc.EmbeddedDriver")
//Delete table if previously created
try {
sql.execute("drop table blogs")
} catch(Exception e){}
//Create table
sql.execute('''create table blogs (
id varchar(200) not null primary key,
title varchar(500)
)''')
//Parse XML and populate the table
def blogs = sql.dataSet("blogs")
feed = new XmlSlurper().parseText(feed)
feed.entry.each {entry ->
blogs.add( id: entry.id.text(), title: entry.title.text() )
}
//Read from table and create Xml
def writer = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(writer)
builder.setDoubleQuotes(true)
builder.feedlist {
sql.eachRow("select * from blogs") { row ->
feedentry(id:row.id) {
title row.title
}
}
}
//Print out XML, and voilà, done!
println writer.toString()
Pretty easy heh? No try-catch blocks, no headaches around setting up and closing database resources, no InputStreams, no importing an external XML parser. And the code even creates the database and table on the fly!!
For those curious the output from running the above is:
<feedlist>
<feedentry id="tag:blogger.com,1999:blog-2241013152284479770.post-720388331940374029">
<title>No Fluff Just Stuff 2008</title>
</feedentry>
<feedentry id="tag:blogger.com,1999:blog-2241013152284479770.post-1855527957885191012">
<title>Career 2.0</title>
</feedentry>
</feedlist>
Which, hehum, proves that I really need to be more active in my blogging.
During the afternoon session we went over the Grails framework, which is highly reminiscent of Rails. Jim showed us how to quickly put together a web site by defining a couple of domain objects and having Grails do its magic by generating the persintance layer and database tables and a nifty front end for CRUD operations on the domain objects. It looked really nice, but started loosing some of its charm once he started mocking with the view GSPs and we came to realize it effectively made any further auto-generation from the domain objects impossible (or you would overwrite your changes). So the lesson learned is to put detailed thought into designing your domain objects up front and save your self some work by having Grails auto-generate your views, controllers and persistence layer (via GORM, a Groovy object relational mapping implementation on top of Hibernate). But know that once you have put some work into customizing your application any changes to your domain objects means you will need to edit your views, controllers and database mappings by hand.
Here are the slides from the PreCompiler.
Day 1
Introducing iPhone SDK - Chris Adamson
This was a session had been looking forward to a lot. I have been a trusty iPhone 3G owner since it was released last July (I even stood in line before stores opened the day it was released!) and have been eyeing getting into iPhone development. The session provided a good overview of what it takes to get into iPhone development and walked through the implementation of a simple application. Unfortunately the starting cost is somewhat high; get a Mac, learn Objective-C, pay for a development license, deal with Apple's registration process, write your app and wait for up to month to get it approved. Objective-C is a Smalltalk inspired C like language dating back to 1986. I must admit that manual memory management and pointers aren't exactly things I have missed for the past 10 years or so. So delving into Objective-C is something I'd do with some hesitation. Actually, Chris Judd's iPhone with Grails presentation on Day 2 got me thinking I might start by doing an iPhone web application rather than native application.
Slides from the presentation.
Three tips to improve your dev process - Jim Holmes
Former Quick Solutions colleague Jim Holmes had an interesting talk on things we can do to improve our software development processes. He discussed the importance of daily standups and retrospectives, and provided tips to improve estimation. The session was mainly memorable for the somewhat heated discussion that materialized between Jim and a few of his audience members, headed by Mary Poppendieck, who as Jim put it "lead him out on a branch and then proceeded to saw it off".
Slides to be posted at FrazzledDad.com.
Erlang: The Basics - Kevin Smith
Very interesting session and by far the one that made my eyes spin the most. As Kevin put it "Erlang Is Weird". If you can not imagine life without for-loops, while-loops or strings, then Erlang is not for you! I enjoyed getting familiar with the language, but to be honest, don't see myself as a hard core Erlang fanboy anytime soon. But due Erlang's strength in dealing with concurrency I imagine the language will continue to prosper in a world where 256 core CPUs will soon be a reality.
Since there are no loops in Erlang, recursion is the name of the game. Here is a simple Erlang code to print out the contents of a list:
print([H|T]) ->
io:format(“~p~n”, [H]),
print(T);
print([]) ->
ok.
I found it interesting that the language has three (!) line terminators (, ; and .), when most of the new generation languages (Ruby, Python, Groovy, Scala, etc.) have gone the route of dropping terminators.
Slides here.
iPhone development with Grails - Chris Judd
Another session I was looking forward to. Chris walked us through the pros and cons of doing native vs. web application development for the iPhone. The pros of native development being:
- Access to native features like GPS, accelerometer and camera.
- Offline access.
- Performance.
- The glamour and marketing associated with having your app in the AppStore.
The pros of web app development being:
- Don't have to learn Objective-C. You can develop with whatever technology you are most comfortable with.
- Deployment under your control.
- Don't have to get a development license.
- Don't have to bury yourself in a mountain of legal agreements.
- The process is on your timeline and not Apple's
Chris then walked us through developing an iPhone web application using Grails with a custom iPhone plugin that he wrote for the iUI JavaScript framework, which allows you to customize the look and feel of your web app to rival that of a native application.
I have been brewing an idea for an application that I would like to write for my phone. Since the benefits of writing it as a native application are limited and clients will require access to a centralized database, I am making it my mission to write it as a Grails web app in 2009. I even went ahead and registered the domain goodweatherlocator.com just now, which should give you some idea about what I am planning to build.
Slides from the session here.
Sexier Software With Flex - James Ward
This was an overview session on how to build applications using Flex. It showed some pretty sexy Flex applications and then walked us through the creation of a basic Flex app using MXML and ActionScript.
I have never been very interested in RIA development, but figured I would at least dip my toe in the pool.
If you are unfamiliar with Flex, check out the tour at http://flex.org/tour.
Day 2
Practices of an Agile Developer - Venkat Subramaniam
As in his keynote a day earlier Venkat was excellent in this no frills Agile session. He provided many good tips on how to get into Agile and how to practice Agile software development, along with some gold nuggets on how to improve yourself as a software developer:
- The most important thing in adopting Agile is attitude.
- Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea was best.
- Learn everything about something and something about everything.
- It is very hard to learn if don't learn continuously. It is incredibly easy if you do it all the time.
- Spend 30 min a day reading something unrelated to your current job.
- Present details and let your customers decide. Developers, managers or business analysts shouldn't make business critical decision - let the business owners make those.
- Run your unit tests on all platforms you plan to support.
- Use standup meetings to keep the team on the same page.
No slides, but Practices of an Agile Developer by Venkat and Andy Hunt a recommended reading. A colleague of mine won a copy of it at the closing ceremony and from my 5 min of browsing through it looked very promising.
Cool Stuff With computer Vision - Scott Preston
Scott showed us his robot Feynman and how he sees the world. Apparently robots are really into Jessica Alba because much of the presentation focused on a beach photo of her, seen through various image filters. When he showed us how his bot can discover and zoom in on her breasts, I noticed the lone female in the room moved uncomfortably in her seat.
All in all this was an entertaining session that gets a 10 on the geek scale.
Slides and photos of Jessica's top here.
Spring 3.0 MVC - Ken Sipe
A nice overview of Spring MVC (mainly 2.5 features) and all the benefits it provides over older MVC frameworks like Struts. Takes "convention over configuration" to the max and greatly reduces the amount of Java code needed for a typical Web application. Or as Ken put it, "The next best thing to Grails"!
Slides to be posted here.
Cloud Computing with .Net - Wesley Faler
The last session of the conference. I figured I couldn't go home without seeing at least one .Net related presentation. Wes walked us through the Cloud Computing concept and how it differs from web farms, grids and clusters. The nuts and bolts of it is essentially computing resources on demand. He got me all excited when describing Amazon's EC2 service and the fact that you can use it with numerous different programming languages. But once he gave us some samples of the pricing, my excitement withered away.
Fancy slides here.
This wraps up my CodeMash 2009 experience. As in previous years I had a lot of fun and will definitely be looking to coming back again. From what I've heard CodeMash 2010 will be even bigger and better.
Sunday, July 27, 2008
No Fluff Just Stuff 2008

10 Things an Architect should know
Speaker: Richard Monson-Heafel
This session was a good eye opener for getting your head out of the sand. A one-liner summary would translate to something like: Stop wasting time arguing about implementation details and start focusing on customer needs!
Below is some paraphrasing of the top 6 noteworthy things I got out of Richard's top 10 list.
People are the Platform
People are the Platform
User interface is the most important part of your system. The point of IT is to make people more productive not to write beautiful systems. What happens underneath the hood is really not that important, as long as it works. A great UI on top of ugly middleware is much better than bad UI on top of pretty middleware.
All Solutions are Obsolete
When picking technology, pick what works best today, don’t try to predict the future.
For example a couple of years ago a lot of people banked on JSF becoming tomorrows golden standard, and are now suffering (to some extent). You can’t really predict what is going to be the popular in the future. Just pick what works best today and stop worrying about future proofing your system. There is no such thing as future proofing... it is a myth.
Data is forever, everything else can change
IT architecture keeps changing, but the data (often) lasts forever.
With that in mind Richard promoted the use of relational databases, as opposed to object databases or XML databases, which are tied to a specific technology. Likewise Richard took some shots at Rails & Grails, for probably getting things wrong in the long run. Basically stating that we should not have systems be generating our databases. We should build the database first to meet the company needs and then the systems on top of the databases. 5 years from now the database might still be there but everything else has changed.
I can agree with this to some extent, as I have had some bad experiences in the past working with tools that try to autogenerate a database based on some higher level entity. Usually what gets generated is somewhat of a mess and not easily reusable by other systems at a later time. On the flipside though, the productivity gains of newer development frameworks make them hard pass on. We just need to be mindful of taming them to some extent to generate maintainable databases.
Flexibility Breeds Complexity
Simplicity can create flexibility, but flexibility will always create complexity.
When designing a system always err towards simplicity.
Building a simple system and adding features to it later probably costs you less in the long run than building a super flexible system upfront to handle all possible future changes.
Know The Business
As a software architect you are in the tough position of having to be an expert on all things related to the technology of the company, but just as importantly you need to know and understand the business of the company you work for. You need to know the business as well as the business people! Remember, it is your job to make the business people more productive. If you don't understand what they do, then how can you help them?
Software Architects Should also be Coders
Get out of your ivory tower and into the trenches. Bits talk, Bulshit walks.
Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. That’s how you see what is working well and what is giving people headache. Pull up a chair and sit next to a developer for an hour. In addition to getting a better feel for what the developer is dealing with you'll be surprised at how hard he/she will work during that hour! :)
So You Have Been Promoted to Tech Lead. What do you Do.
Speaker: Mark Johnson
This session brought up some useful points for us Tech Leads to think about.
A few of them were:
Flexibility Breeds Complexity
Simplicity can create flexibility, but flexibility will always create complexity.
When designing a system always err towards simplicity.
Building a simple system and adding features to it later probably costs you less in the long run than building a super flexible system upfront to handle all possible future changes.
Know The Business
As a software architect you are in the tough position of having to be an expert on all things related to the technology of the company, but just as importantly you need to know and understand the business of the company you work for. You need to know the business as well as the business people! Remember, it is your job to make the business people more productive. If you don't understand what they do, then how can you help them?
Software Architects Should also be Coders
Get out of your ivory tower and into the trenches. Bits talk, Bulshit walks.
Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. That’s how you see what is working well and what is giving people headache. Pull up a chair and sit next to a developer for an hour. In addition to getting a better feel for what the developer is dealing with you'll be surprised at how hard he/she will work during that hour! :)
So You Have Been Promoted to Tech Lead. What do you Do.
Speaker: Mark Johnson
This session brought up some useful points for us Tech Leads to think about.
A few of them were:
- Requirements Acceptance Criteria
- 66% of requirements have no business value
- When you are on a project that gets flooded with new requirements, try to put each one of through the following pick list:
Any requirement that ends up in the "Kill" category you should bring back to the business (or product owner) and explain your case for getting that requirement dropped. On the flip side be more open to requirements that have high business value but low complexity, risk and cost. If you can get some of those in, in favor of throwing out a couple of "killers" you might make your project more likely to succeed, even though business people keep wanting to change things on you. Also, don't just automatically say no to every new request (over defend you project). Evaluate it via the above pick list and try to work out what is in the best interest of everyone involved. - Delegate
(This might have been the hardest thing for me to learn when I stared doing tech lead work) - Stop playing superman! Don't assign all the hardest tasks to yourself. You won't have time to implement them properly. Trust your developers and they will usually reward you.
- Don't go to every meeting! In most meetings nothing noteworthy happens. Delegate attending some meetings to your teammates.
- Once you come up with a plan, share it with everyone
- Make sure you have peoples buy in to what you are planning to do. If you run into trouble later people will be much more willing to help you out if you included them from the beginning.
Getting Started with BPEL
Speaker: Mark Johnson
I have to admit that this session sent a few gusts of cold shivers down my spine. I did not know much about BPEL and was kind of curious to see what the fuss was about. After doing some preaching about BPEL being XML driven and one of its design goals being "Not to define a graphical representation of processes", a few slides into the presentation Mark brought up the NetBeans BPEL IDE. To my shock I found myself staring at something that looked an awful lot like a WLI JPD (WebLogic Integaration Java Process Definition)! It tied together several web services in an elegant looking flow diagram, with forks and splits and what have you. Even some visual transformations of data from one web service passed to another. Now, for anyone not familiar with the JPD technology, it tries to do pretty much the same thing, basically tie together multiple service calls and transformations in a nice looking flow diagram. On the surface it sounds great, but my actual experience in dealing with the JPD technology has brought about multiple frustrations:
- The flow through your JPD is written in a custom XML language which ties back to autogenerated Java code that programmers are discouraged to change
- It breaks many key OO concepts such as
- No encapsulation (everything that holds data is a public global variable in the JPD class),
- No inheritance. Two JPDs for similar services are pretty much a copy-paste of eachother.
- One business method per JPD. There is only one entry point into your typical JPD.
- Some of the JPD UI language concepts don't work as expected
- For example the JPD Parallel node, which is meant to call multiple services in parallel and then wait for all to finish before proceeding onto the next node in your flow. After some hair pulling I discovered that actually doing things in sequence rather than parallel resulted in much faster code! The parallel node ends up spawning a new thread for each service call, which can be very taxing on your app server resources.
- When writing JPDs, a lot of time is spent trying to figure out how to get something working, as opposite to focusing on writing business logic.
- You never really know what is going on underneath the hood.
- WebLogic claims that you don't need to know anything about how the JPDs are implemented. But in actuality you will run into problems that require you to understand what is really going on when your JPD is being executed (like with the parallel processing nodes) . Over time you will come to realize that underneath all the glory you have a ton of autogenerated EJBs and JMS messages hard at work, but little documentation on what is really taking place.
- Most JPDs are hard to read, even for developers!
- The idea of JPD being a great tool for you to communicate your process to business people was not my experience during the couple of years I used the technology. Most of our JPDs ended up being complicated and convoluted, and we found ourselves using sequence diagrams as a more useful tool to communicate design to our business analysts. Over time we learned to simplify our JPDs, but even so I never saw them being used much when communicating with the business.
At the end of the day I decided to apply a duck typing analogy on BPEL. If it acts like a JPD and quacks like a JPD, then it must be a JPD! :-) I hope I will not have to deal with this technology in the future.
Subscribe to:
Posts (Atom)