ISE Blog

What we have to say, what you want us to hear.

That’s how our blog works. It’s interactive. Let’s learn together.

Uniting to Give Back to the Community

Nov 08, 2018 | by Meredith Godar, Software Engineer | Tags: Company Culture

Since 2014, the Philanthropy Committee at ISE has been dedicated to uniting ISE to give back to the community.  Each year the committee plans about one event per quarter focused on different charitable organizations within the community.  We also hold blood drives throughout the year on site at the Coralville office. 


Meet Our Team: Rich Lineback

Nov 01, 2018 | by Daniela Williams, Project Manager | Tags: Meet Our Team

Meet Our Team Q&A series. My name is Daniela Williams, Project Manager at ISE, and I’ll be asking ISE team members questions to help give insight into what makes us tick. 

Today I'm interviewing Rich Lineback, Director of Business Development for our Professional Services division and our most recent addition to the ISE Leadership Team.  In his short time here, he's already been an active force in pursuing new business opportunities while injecting humor along the way.


What’s Wrong with Monoliths?

Oct 25, 2018 | by Samuel Thurston, Software Engineer | Tags: Cloud

Much of the writing I’ve done in this space over the past few years has been geared towards microservices and scalable architectures based on innovations in cloud providers’ technologies.  But sometimes the way that we talk about microservices architectures implies that they are the only good solution and monoliths are bad.  Are they? 


Analysis vs. Doing Something

Oct 18, 2018 | by Andrew Smith, Principal Architect | Tags: Agile

How long should a team spend analyzing something before doing something?

A team I work with recently used a "spike" to investigate how to implement a new system capability. The spike was open for two sprints, although I am not sure how much effort was expended over the course of those two sprints. The fact of this spike being open for two sprints made me curious about the trade-offs made… given the agile value of Working Software over Comprehensive Documentation, was the team leaning too far in the direction of comprehensive documentation? And if so, how would they know? 

In thinking about this trade-off, I like the following thought experiment… what would each extreme look like?